Improve support for stalled-Git messaging

[FichteFoll]

I'm trying out this package and have problems with the status view.

What I can do:

• stage or unstage files
• navigate files with , and .

What I can't do (read: nothing happens):

• refresh the view after staging/unstaging
• show "diff" or "inline diff"
• stage/unstage all files (a or U)
• diff all/cached files
• commit

I checked with sublime.log_commands(True) that commands are correctly being executed. There are no errors in the console.
I'm running on Win7 and ST 3113.

[FichteFoll]

I figured out what the problem was: There was a git process running from when I attempted to "push" to the remote but that never finished or did anything (not even show an error or something). When I killed the process, all the commands that I seemingly "queued" during this were suddenly run.

What's even weirder is that this even prevented InactivePanes from having its EventListener hooks run (notably on_activated and on_deactivated), which were also seemingly appended into the queue.

This definitely needs some attention.

[divmain]

I've been mulling over this for awhile, but you're the first to bring this up with a real-world issue. At the moment, GitSavvy simply uses the non-UI thread (exposed via sublime.set_timeout_async) for all Git operations. If you had a hung Git process, it would make sense that other packages might be blocked if they rely on this thread also.

Now that you've brought it up, here's what I've been considering:

• Add a GitSavvy-only thread for running git commands.
• When a command is running, set a (lockable) is_running variable indicating that a git command is running.
• If a user-driven action occurs (versus passive updates, like those for the status bar) that would normally result in a Git command, check is_running. If True, notify the user that git is still running and that they will have to wait.
• Expose GitSavvy: kill git process command to stop any long-running git commands that are no longer wanted.

Thoughts?

[stoivo]

I think the 2. Approach wont work good if you started the fetch or pull from outside GitSavvy?

I think to expose GitSavvy: kill git process sounds good. Do you know if we can make it so if the git command takes more than 10 seconds we will prompt the user and tell that the git operation took more than 10 seconds and you may want to GitSavvy: kill git process.

[FichteFoll]

@divmain, yes, the _async thing could explain it. Interesting, I haven't though of that, but it appears that ST does indeed keep a UI and an async thread that only ever executes one callback and the others are queued. Including the on_*_async event hooks.

In that case, yes, you should definitely be launching your own threads. The other suggestions sound very good too.

[kaste]

We wait max 120 seconds (which is a random number of course) or kill. Interesting part is that we need to wait to inf iff the git call opens for example Sublime Text itself for editing a message, or a call to git gui, maybe even in daemon mode.

For typical git calls 120 seconds is way above what to expect. Usually we "stall" only when we go over the internet and the OS thinks we're connected but we actually only get 1 byte per minute ("lie-fi") anyway.