Dec
9

Fix GIT Lock after GIT Crash

If you ever see the following message when trying to commit your code to a GIT repository.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.


The solution is very easy, just delete the .git/index.lock file
~ rm /yourhomedir/.git/index.lock

Then you need to do a git reset
~ git reset

That should do the trick. Let me know if this worked for you.

26 Comments to “Fix GIT Lock after GIT Crash”

  • It worked . Thanks a lot!

    • Great to hear that this solution worked for you.

  • I am getting the following error while push the commit

    git push origin master

    fatal: unable to create 'refs/heads/master.lock': File exists fatal:
    The remote end hung up unexpectedly

    I thought of removing the lock file (refs/heads/master.lock) from my local machine. But this file is not available.

    I think this file is in git server.

    If i remove this file from server will it solve the issue? ( if the file exists in server)

    What is the origin of this issue?

  • Merci beaucoup πŸ™‚

  • Works! Thx!

  • Worked for me too. Thanks a lot! πŸ™‚

  • another thankful git user πŸ™‚

  • Thanks, worked like a charm.

  • worked!!, thx

  • Working good. Thank u

  • Saved me, thanks

  • Sava my time. Thanks a lot!!!

  • That worked great! Thanks!

  • Worked! Nice! πŸ˜€

  • Hi, it works. Thanks.

  • Doesn't work for me… I remove it and after doing git reset I get:

    Rename from .git/index.lock to .git/index failed.. Should I try again? (y/n)

    Pressing y, asks the question forever… Pressing no leaves me with: fatal: unable to write new index file.

  • Work perfectly

  • It works…. Nice. Thanks

  • thanks a lot

  • Savior!!!

  • Worked!! thanks a lot!!

  • It works for me, thank you

  • Worked like a charm. Thanks!

  • oooh… nice! saved my day! thanks! πŸ™‚

  • To the question why this can happen:

    git usually always removes the lock file, except for reasons like:

    – Bugs in git
    – git was hard killed in the middle of an operation
    – The filesystem brought back the file in question. This i. E. can happen due to things like recovery actions, reordeded barriers, network lag or other unclear situation on Union type filesystems.
    – Two git processes access the same tree over different type of paths (like you run NFS parallel to CIFS on the same tree) such that the resulting parallel operations lack atomicity.

    But:

    Why the git reset?

    I never needed it. “git reset” is the same as “git reset HEAD” which simply does nothing much useful except wasting your time. Well, it might read in some git data structures such that you can see if there is a corruption, but I am not aware of anything else it does and is needed in this situation.

    FYI: The existing lock trouble is an annoying and very common event at my side. I think it mostly stems from following hack at my side:

    https://gist.github.com/hilbix/2bd39b26280ad7d99712

    Note this hack is needed because GIT_PS1 can delay the shell prompt too much (1s is too much, right?) in case the current directory, for example, is on a slow network share (which is quite often the case). In that case it can even look like the shell is dead, because pressing ^C (while the prompt is evaluated) usually leads to another prompt, evaluating the interrupted git-prompt again. Hence you are stuck in a loop. If that takes several minute or more (because the CWD is heavily loaded) you are stuck until you switch off GIT_PS1 before entering certain directories. Which is painful, hence the automation at my side. The index.lock-Problem is something I have to live with, sigh.

  • This works. Thanks for the solution.

Leave a comment