'Failed to create .git/index.lock'

'Failed to create .git/index.lock'

[Andreas Krey]

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

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 'Failed to create .git/index.lock'

[Lars Schneider]

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 09 Feb 2016, at 08:58, Andreas Krey <a.krey@gmx.de> wrote:
> 
> 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
> 
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 'Failed to create .git/index.lock'

[Andreas Krey]

On Mon, 15 Feb 2016 18:06:33 +0000, Lars Schneider wrote:
> 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.

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:

> (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.

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

> Does your Git process run on Windows, too?

No. RHEL7 Linux.

> Is there a possibility that you issue Git commands in parallel?

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

> I also have read that certain anti virus software can trigger these errors on Windows.

That is an ugly problem indeed.

> 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?

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

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800