{"action":"reopened","issue":{"url":"https://api.github.com/repos/magit/magit/issues/2708","repository_url":"https://api.github.com/repos/magit/magit","labels_url":"https://api.github.com/repos/magit/magit/issues/2708/labels{/name}","comments_url":"https://api.github.com/repos/magit/magit/issues/2708/comments","events_url":"https://api.github.com/repos/magit/magit/issues/2708/events","html_url":"https://github.com/magit/magit/issues/2708","id":162150434,"number":2708,"title":"Make magit more robust in the face of transient index.lock collisions","user":{"login":"jsyjr","id":1302939,"avatar_url":"https://avatars.githubusercontent.com/u/1302939?v=3","gravatar_id":"","url":"https://api.github.com/users/jsyjr","html_url":"https://github.com/jsyjr","followers_url":"https://api.github.com/users/jsyjr/followers","following_url":"https://api.github.com/users/jsyjr/following{/other_user}","gists_url":"https://api.github.com/users/jsyjr/gists{/gist_id}","starred_url":"https://api.github.com/users/jsyjr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jsyjr/subscriptions","organizations_url":"https://api.github.com/users/jsyjr/orgs","repos_url":"https://api.github.com/users/jsyjr/repos","events_url":"https://api.github.com/users/jsyjr/events{/privacy}","received_events_url":"https://api.github.com/users/jsyjr/received_events","type":"User","site_admin":false},"labels":[{"id":94495,"url":"https://api.github.com/repos/magit/magit/labels/bug","name":"bug","color":"e10c02","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":19,"created_at":"2016-06-24T13:48:45Z","updated_at":"2016-12-10T17:08:54Z","closed_at":null,"body":"As I have become more proficient at using magit's support for interactive rebasing (and its moral equivalents, _e.g._ cF) I encounter increasingly frequent instances where magit abandons a rebase claiming that it could not acquire an index.lock.  The diagnostic in the magit-process buffer says:\n\n> fatal: Unable to create '/path/to/workspace/.git/index.lock': File exists.\n> \n> If no other git process is currently running, this probably means a\n> git process crashed in this repository earlier. Make sure no other git\n> process is running and remove the file manually to continue.\n\nHistorically - as instructed - I have simply rm-ed the file and resumed the rebase.  Lately though I have started checking to see if the file actually exists and have yet to find and instance when it does.  This leads me to believe that magit is aggressively issuing a subsequent git command before a (possibly asynchronous?) portion of the previous command has fully cleaned up.\n\nIf my hypothesis is correct then magit could be made more robust by adding logic to special case index.lock failures.  I suggest spinning for a limited amount of time waiting for the lock to disappear before reporting a failure.  If the lock does disappear on its own then magit can simply retry the original git command.\n"}}
{"actor":{"display_login":"tarsius"}}