Error: Unable to create 'C:/Myproject/. git/index.lock': File exists

Asked

Viewed 3,400 times

2

Suddenly I went to "commit" my project, when out of nowhere appeared this message:

Erro: Unable to create 'C:/MyProject/.git/index.lock': File exists.

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.

Even before the commit, when using the command #git add . already appeared the message. I did not understand what might have happened. When exactly this occurs? How can I solve this problem?

git commit
  • 1

    You are saying that the file exists. Navigate to the location and delete it.

  • Atomization of the operation, very interesting subject! I will write an answer on the subject. I say this because of the competition of cases

2 answers

3


A repository git is a specific use database. It maintains commits (its main data structure), branchs (containing name and reference to a commit) and tags (contains the same information as a branch).

The difference between tag and branch is not within the scope of this answer

There is a structure similar to a commit special called head. She has some operations:

  • modify content/list (like adding, removing files, changing lines, renaming files)
  • transform into commit

The transformation into commit will cause the structure to have a SHA1 of its own commit, have a commit father, an author and, also, will move the pointer of the branch work. After transformation into commit, head will be with an empty structure.

The list commands are, among others:

The command to transform head in commit is:

  • commit

Now, these operations are large, and therefore may take a long time to materialize. Imagine that you decided to rename a Java package from br.com.acklay for plu.to.nio.marviana, and that all other Java sources point to classes. You would need to list the 22936 source files. This will take a while...

So, inadvertently, you try to commit the change:

git commit -m 'decaimento radioativo do Cleidi'

Well, if the system had no way of identifying that the head was being modified, the commit generated would represent a foreign and possibly corrupted state of the data, so it is necessary to have some form of CPI between the two proceedings.

In this case, the CPI strategy chosen by git was the atomic creation of a lock file. This strategy is known for lockfile.

Later I find the *Nix command that makes the atomic creation of a file

In case, as there is no server waiting to hear a message, a process git needs to decide for yourself by observing the environment (OS included as part of the environment) whether it can make critical changes or not. So he makes the following call to the operating system:

So, please, create for me the file .git/index.lock? Returns me success if it is only if I was the one who managed to create this file, or if it already exists return me failure

For which, there are two answers that the OS can provide:

It’s here, little one git, you created the file

Or, in case the file already exists (or just created by another process in parallel):

Hey, pet! This file already exists!

If the file previously exists (and therefore the error occurred), the git aborts gracefully with that message you’ve been received.

If the file was created (and therefore successful), the git is happy in its processing and, when you have finished the required activity, will remove the lock file.

When this message appears?

In healthy cases, when there is some critical operation underway by another process git in parallel.

In strange cases, the last process git who requested this lock could not release it (died prematurely? Poor thing...). So the file is loose there for no greater purpose. Might indicate some possible theoretical corruption of head, as it can also be just a forgotten junk.

How to solve?

In healthy cases, the ideal is to wait. And ensure that there won’t be another process trying to crash your repository in the meantime. If you use the SourceTree, strongly recommend that you do not open your window, minimize it or even close it. The SourceTree only triggers a process git when it is in the foreground, and often expects some operation on the user (even if this operation is "focus on the window").

In strange cases, just remove the file index.lock and ensure that the repository is healthy.

During a command of fetch, I had to abort the git. When I try to spin it now, he says it himself:

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.

Translating:

If there is no other git process running now, it probably means that a git process broke in this repository earlier. Make sure there is no other git process running and manually remove the file to continue.

Then, on the command line, git indicates whether to do as described above.

  • 1

    Well, it happened exactly when I was using Visual Code synchronously using git, so I opened another instance of git using CMD. But cool, your answer is even interesting. heheh

1

Run the code below and then try to resume the process you wanted to do:

rm -f ./.git/index.lock

  • Thank you. The fellow above ended up getting excited and said about it!

Browser other questions tagged git commit

You are not signed in. Login or sign up in order to post.