'Failed to create .git/index.lock'

Hi all,

I have a single workspace where executing merges occasionally leads to a left-over .git/index.lock file that prevents me from adding resolved conflicted files.

I'm running a sped-up integration/feature branch process, and the merges and conflict resolution are automated. But the index.lock thing is happening only in one repo of the three that are doing this.

Any hints as to debugging this?

(It is not a running background gc, the lock file is still around when there is nothing running any more, for hours.)

Andreas

Hi Andreas,

I am looking into a similar issue with SourceTree on Windows right now. However, in my case it only happens when I switch branches. I investigated the Git commands that SourceTree triggers and it looks like it is doing something like this:

(1) Run checkout command git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false checkout MY-BRANCH

(2) Run rev-parse command git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false rev-parse HEAD^1

My assumption is that SourceTree triggers these two commands in parallel and sometimes (2) locks the repo first which makes (1) fail. Does your Git process run on Windows, too? Is there a possibility that you issue Git commands in parallel? I also have read that certain anti virus software can trigger these errors on Windows.

I looked through the Git code found that increasing "core.packedrefstimeout" [1] might help in some cases that trigger this error [2] but not in others [3]. In my case this seems to help. Maybe it's worth a try for you, too?

Cheers, Lars

[1] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/refs/files-backend.c#L2070 [2] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/lockfile.c#L171-L178 [3] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/builtin/update-index.c#L1156

On Mon, 15 Feb 2016 18:06:33 +0000, Lars Schneider wrote:

Semi-bingo. That is actually a difference between the workspace this happens in and the others. This one works on many branches; the others clone anew for each new branch.

I investigated the Git commands that SourceTree triggers and it looks like it is doing something like this:

That would be partly a bug in SourceTree to do so.

No. RHEL7 Linux.

I don't think so, except for background GC (which isn't quite background - one phase seems to still run foregrounded).

That is an ugly problem indeed.

I may need to look into that. Because sometimes the lock causes my automatic process to fail but the lock file isn't there anymore when I get to cleanup. But sometimes it keeps existing.

Andreas