{"thread":{"id":"41375","subject":"'Failed to create .git/index.lock'","startedAt":"2016-02-09T07:58:29Z","lastAt":"2016-02-15T21:34:36Z","messageCount":3,"participants":["Andreas Krey","Lars Schneider"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"277794","messageId":"20160209075829.GA12331@inner.h.apk.li","threadId":"41375","inReplyTo":null,"subject":"'Failed to create .git/index.lock'","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2016-02-09T07:58:29Z","receivedAt":"2016-02-09T07:58:29Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"Hi all,\n\nI have a single workspace where executing merges\noccasionally leads to a left-over .git/index.lock file\nthat prevents me from adding resolved conflicted files.\n\nI'm running a sped-up integration/feature branch process,\nand the merges and conflict resolution are automated.\nBut the index.lock thing is happening only in one repo\nof the three that are doing this.\n\nAny hints as to debugging this?\n\n(It is not a running background gc, the lock file\nis still around when there is nothing running\nany more, for hours.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"278167","messageId":"5B9871D2-395D-4F0C-94FB-278832FCFD76@gmail.com","threadId":"41375","inReplyTo":"20160209075829.GA12331@inner.h.apk.li","subject":"Re: 'Failed to create .git/index.lock'","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-02-15T17:06:33Z","receivedAt":"2016-02-15T17:06:33Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi Andreas,\n\nI 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:\n\n(1) Run checkout command\ngit.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\n\n(2) Run rev-parse command \ngit.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\n\nMy 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.\n\nI 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?\n\nCheers,\nLars\n\n\n[1] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/refs/files-backend.c#L2070\n[2] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/lockfile.c#L171-L178\n[3] https://github.com/git/git/blob/494398473714dcbedb38b1ac79b531c7384b3bc4/builtin/update-index.c#L1156\n\n\n\n> On 09 Feb 2016, at 08:58, Andreas Krey wrote:\n> \n> Hi all,\n> \n> I have a single workspace where executing merges\n> occasionally leads to a left-over .git/index.lock file\n> that prevents me from adding resolved conflicted files.\n> \n> I'm running a sped-up integration/feature branch process,\n> and the merges and conflict resolution are automated.\n> But the index.lock thing is happening only in one repo\n> of the three that are doing this.\n> \n> Any hints as to debugging this?\n> \n> (It is not a running background gc, the lock file\n> is still around when there is nothing running\n> any more, for hours.)\n> \n> Andreas\n> \n> -- \n> \"Totally trivial. Famous last words.\"\n> From: Linus Torvalds \n> Date: Fri, 22 Jan 2010 07:29:21 -0800\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"278201","messageId":"20160215213436.GB16220@inner.h.apk.li","threadId":"41375","inReplyTo":"5B9871D2-395D-4F0C-94FB-278832FCFD76@gmail.com","subject":"Re: 'Failed to create .git/index.lock'","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2016-02-15T21:34:36Z","receivedAt":"2016-02-15T21:34:36Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Mon, 15 Feb 2016 18:06:33 +0000, Lars Schneider wrote:\n> Hi Andreas,\n> \n> I am looking into a similar issue with SourceTree on Windows right now. However, in my case it only happens when I switch branches.\n\nSemi-bingo. That is actually a difference between the workspace this\nhappens in and the others. This one works on many branches; the others\nclone anew for each new branch.\n\nI investigated the Git commands that SourceTree triggers and it looks like it is doing something like this:\n\n> (1) Run checkout command\n> 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\n> \n> (2) Run rev-parse command \n> 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\n> \n> My assumption is that SourceTree triggers these two commands in parallel and sometimes (2) locks the repo first which makes (1) fail.\n\nThat would be partly a bug in SourceTree to do so.\n\n> Does your Git process run on Windows, too?\n\nNo. RHEL7 Linux.\n\n> Is there a possibility that you issue Git commands in parallel?\n\nI don't think so, except for background GC (which isn't quite background -\none phase seems to still run foregrounded).\n\n> I also have read that certain anti virus software can trigger these errors on Windows.\n\nThat is an ugly problem indeed.\n\n> 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?\n\nI may need to look into that. Because sometimes the lock causes my\nautomatic process to fail but the lock file isn't there anymore when\nI get to cleanup. But sometimes it keeps existing.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"}]}