Inhibit restart while git operation in progress

[andyw8]

Idea is from https://stackoverflow.com/questions/47901986/how-to-tell-if-a-git-operation-is-in-progress

We want to prevent Ruby LSP from repeatedly restarting when doing a long operation, such as pulling a branch with many new commits. (Normally we restart on changes to Gemfile.lock).

This doesn't fully solve the problem though: For example, if you do a git pull on a large repo, and there are several commits changing Gemfile.lock, index.lock will be created and deleted several times through the pull.

But I believe this will prevent Ruby LSP attempting to boot while there's an incomplete Gemfile.lock.

[github-actions]

This pull request is being marked as stale because there was no activity in the last 2 months

[vinistock]

We want to prevent Ruby LSP from repeatedly restarting when doing a long operation, such as pulling a branch with many new commits. (Normally we restart on changes to Gemfile.lock).
But I believe this will prevent Ruby LSP attempting to boot while there's an incomplete Gemfile.lock.

Can you explain your train of thought here? When you say incomplete Gemfile.lock, when does that happen? Even if you pull many commits, aren't the files update in a single operation at the end?

[andyw8]

Can you explain your train of thought here? When you say incomplete Gemfile.lock, when does that happen? Even if you pull many commits, aren't the files update in a single operation at the end?

It seems not: https://stackoverflow.com/questions/49362006/does-git-pull-atomically-write-files

[vinistock]

I just tested this and I don't think it fully solves the problem.

As you pointed out in the description, index.lock gets created and deleted multiple times during an operation. By adding it to the list of watchers, it makes us restart multiple times.

Additionally, it forces us to restart even if the contents of the git pull didn't modify the lockfile at all.

I think part of the problem is that we're currently restarting after some git operations (rebase, bisect...) but those watchers aren't playing well with the lockfile watchers.

This is what currently happens:

1. We detect that the lockfile was updated, we enqueue a restart with the 5 second debounce
2. Immediately after we also detect that a git operation is happening, so we add the guard to block the restart
3. Once the git operation is finished, we enqueue a new restart

I think we need to rework how this is happening so that we can ensure the server is only ever restarted once due to these sorts of changes.

We need a kind of debounced semaphore, where the git operations can lock the restart until the user has completed them.