asynchronous git prompt updates

[robertream]

these changes speed up the git prompt, with the side effect that the prompt will be eventually consistent

Start-Prompt turns the asynchronous prompt on
Stop-Prompt turns the asynchronous prompt off

[dahlbyk]

Very interesting... I'd considered trying something like this long ago but never got very far - nice work! Are there any leaks if the shell is closed without calling Stop-Prompt?

Let me give this a try for a while...

[robertream]

Thanks,

If the shell process is closed, of course there will be no leaks, but I am
not sure if there are leaks when a shell is closed while running in
a host process.

-Robert

On Fri, Jun 1, 2012 at 6:38 PM, Keith Dahlby <
reply@reply.github.com

wrote:

Very interesting... I'd considered trying something like this long ago but
never got very far - nice work! Are there any leaks if the shell is closed
without calling Stop-Prompt?

Let me give this a try for a while...

---

Reply to this email directly or view it on GitHub:
#51 (comment)

[robertream]

With the latest commit I made the default behavior for Start-GitPrompt is to update the status synchronously, in which case it caches the status and only invalidates the cache asynchronously, and only when files are changed in the repository. This is similar to #52, but it allows for ignore file patterns to filter out non-essential file changes. My intention is for these patterns to be based on the ,gitignore file settings.

[dahlbyk]

I almost wonder if it would be worth adding a repository watcher component to libgit2sharp to provide Git-aware change notifications (excluding ignored files, etc). Seems like it could be useful to something like GH4W.

/cc @nulltoken @tclem @haacked @xpaulbettsx @aroben

[robertream]

yeah, it seems like a feature that would be useful for other CLR based git tools as well

[tclem]

That would be awesome.

On Jun 5, 2012, at 3:22 PM, Keith Dahlby dahlbyk@noreply.github.com wrote:

I almost wonder if it would be worth adding a repository watcher component to libgit2sharp to provide Git-aware change notifications (excluding ignored files, etc). Seems like it could be useful to something like GH4W.

/cc @nulltoken @tclem @haacked @xpaulbettsx @aroben

---

Reply to this email directly or view it on GitHub:
#51 (comment)

[nulltoken]

I almost wonder if it would be worth adding a repository watcher component to libgit2sharp to provide Git-aware change notifications (excluding ignored files, etc).

In order to avoid duplicating the "ignore" logic, wouldn't this invoke repo.Index.retreiveStatus(filepath) for each and every "modified/added" notification?

[dahlbyk]

In order to avoid duplicating the "ignore" logic, wouldn't this invoke repo.Index.retreiveStatus(filepath) for each and every "modified/added" notification?

Potentially, though the exposed file status could be lazy to avoid the perf hit unless it's needed.

[nulltoken]

Potentially, though the exposed file status could be lazy to avoid the perf hit unless it's needed.

I'm not sure I'm able to picture the whole design. Let me try:

• So, a FileSystemWatcher would notify a component of each and every change in the workdir
• This component would cache all those changes, maybe deduplicate them
• When an external client (the UI) needs to display the refreshed status, the component would lazily retrrieve the status of each file

Is that it?

[dahlbyk]

You would also need to monitor the repo (e.g. HEAD changing with a checkout).

The posh-git use case is pretty simple - if anything interesting (either in repo, or in workdir and not ignored) changed, fetch a full status update. Other consumers might be interested in more fine-grained events (e.g. HEAD changed, index changed, workdir changed).

[robertream]

Perhaps first start out with factoring out any .gitignore filter predicates so that consumers of the library can compose them with a watcher as they see fit.... SRP/SoC

[jamesmanning]

while it would be tied to the 'console' host of PowerShell, I was wondering if it seems reasonable to have something similar to this approach with status on a timer, but having it update the console async to the prompt?

Since I currently have my prompt put the git status on its own line, it seems reasonable that at prompt rendering time, just store off the current cursor position (where the git status should be written) in a global variable (maybe $global:StatusTargetLocation = [console]::CursorTop) and then fire off the git status job/timer thingy. When it returns, we can write the status string we calculated out to that location in the console.

We could likely use (as-is or close) the WriteTo-Pos function from this blog post (and potentially other bits/tricks from the post as well :)

http://blogs.technet.com/b/heyscriptingguy/archive/2010/03/26/hey-scripting-guy-march-26-2010.aspx

It would definitely depend on the status being on its own line (since we won't know ahead of time how long the status string will end up being and definitely don't want to either overwrite or shift whatever the rest of the contents of their prompt), and would only work in the console host, but does this seem like it would work?

Similar to the previous async approach, you'd want to ensure there was only one outstanding status call at a time instead of hitting enter 10 times firing off git status 10 times :)

Thanks!

[robertream]

Yeah, I actually tried to get this working too. I couldn't figure out a way
to get the changes scheduled on the console thread in one batch, so moving
the cursor around and then outputting characters to the console one at a
time from the timer thread would interfere with executing programs and did
not provide a good user experience. I only spent a couple hours on it
though, and since I upgraded to an SSD on all my Windows development
machines the need for asynchronous updates has gone away anyhow. So now I
prefer to just use the asynchronous cache invalidation.

On Tuesday, November 13, 2012, James Manning wrote:

while it would be tied to the 'console' host of PowerShell, I was
wondering if it seems reasonable to have something similar to this approach
with status on a timer, but having it update the console async to the
prompt?

Since I currently have my prompt put the git status on its own line, it
seems reasonable that at prompt rendering time, just store off the current
cursor position (where the git status should be written) in a global
variable (maybe $global:StatusTargetLocation = [console]::CursorTop) and
then fire off the git status job/timer thingy. When it returns, we can
store off the current cursor position(wherever the user is typing) in a
local, use [console]::setcursorposition(0, $global:StatusTargetLocation) to
go back to the right line, write out the status string, then
[console]::setcursorposition again to put the cursor back to where it was.

It would definitely depend on the status being on its own line (since we
won't know ahead of time how long the status string will end up being), and
would only work in the console host, but does this seem like it would work?

Similar to the previous async approach, you'd want to ensure there was
only one outstanding status call at a time instead of hitting enter 10
times firing off git status 10 times :)

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/51#issuecomment-10346023.

[dahlbyk]

Cursor manipulation makes me pretty nervous...seems like it would be really difficult to test sufficiently to have confidence that it will "just work".

[jelster]

How about putting it into the prompts window title? Is that feasible?

That wouldn't force cursor magic, and doesn't interrupt the user.

Prompt could display branch, title displays revision and status info

Sent from my Windows Phone

---

From: Keith Dahlbymailto:notifications@github.com
Sent: ý11/ý14/ý2012 11:26 AM
To: dahlbyk/posh-gitmailto:posh-git@noreply.github.com
Subject: Re: [posh-git] asynchronous git prompt updates (#51)

Cursor manipulation makes me pretty nervous...seems like it would be really difficult to test sufficiently to have confidence that it will "just work".

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/51#issuecomment-10375132.

[dahlbyk]

Between #319 and #208 we should be in a better spot performance-wise. I'm going to go ahead an close this, but do keep an eye out for an upcoming release with those improvements and leave a note on #78 if you're still having issues.

I do appreciate the effort you put into this several years ago!