{"thread":{"id":"50712","subject":"Possible race condition with git-rebase + .git/index.lock","startedAt":"2019-03-11T22:17:54Z","lastAt":"2022-10-28T17:35:43Z","messageCount":14,"participants":["Sergio Durigan Junior","Eric Sunshine","Duy Nguyen","Elijah Newren","Phillip Wood","Jeff King","Mingun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"371199","messageId":"87k1h55bx0.fsf@sergiodj.net","threadId":"50712","inReplyTo":null,"subject":"Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-11T21:38:51Z","receivedAt":"2019-03-11T22:17:54Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"Hi there,\n\nI've been bit by this bug many times, and always forget to report it\nhere, but this time I finally remembered.\n\nThe scenario is this:\n\n- I have a local repository which tracks the upstream of the project.\n\n- I have 120+ local commits.\n\n- Every week or so, I have to rebase my local commits on top of\n upstream's origin/master.\n\nThe workflow is simple:\n\n # git fetch origin && git rebase origin/master\n\nThis works without problems most of the time (well, usually there are\nconflicts and all, but that's a burden I have to carry). However,\nsometimes I notice that git fails with:\n\n # git rebase origin/master\n ...\n Applying: commitX\n Applying: commitY\n Applying: commitZ\n fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n\nThe first thing I did was to check whether the index.lock file existed,\nbut it doesn't.\n\nI also I thought it might have something to do with \"commitZ\", but after\nI ran \"git rebase --abort\" and tried rebasing again, I noticed that it\nwould stop at another commit.\n\nThis seems like a race condition, but after inspecting builtin/rebase.c\nit doesn't seem like the \"git am\" commands are run in parallel (and it\nwouldn't make sense if they did, anyway).\n\nI tried using GIT_TRACE, but haven't seen any useful information in the\nlogs. I tried using the \"next\" branch, and found that the problem\nexists there as well. I wonder if anyone else has seen this problem.\n\nThanks,\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371203","messageId":"CAPig+cS_NLgwr6F2OqMpMZ3GBO-Cyru3G3UBxiT4ULJ_V1Bqvg@mail.gmail.com","threadId":"50712","inReplyTo":"87k1h55bx0.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2019-03-11T22:50:20Z","receivedAt":"2019-03-11T22:50:33Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior\n wrote:\n> # git rebase origin/master\n> ...\n> Applying: commitX\n> Applying: commitY\n> Applying: commitZ\n> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>\n> The first thing I did was to check whether the index.lock file existed,\n> but it doesn't.\n\nWhat platform is this on? If Windows, I'm wondering if something (such\nas a virus scanner) is holding the lock file open long enough to\nprevent Git from actually deleting it (and perhaps Git doesn't notice\nthe failed deletion -- until the next time it tries to take the lock).\n"},{"id":"371204","messageId":"87bm2h58fy.fsf@sergiodj.net","threadId":"50712","inReplyTo":"CAPig+cS_NLgwr6F2OqMpMZ3GBO-Cyru3G3UBxiT4ULJ_V1Bqvg@mail.gmail.com","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-11T22:53:53Z","receivedAt":"2019-03-11T22:53:57Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Monday, March 11 2019, Eric Sunshine wrote:\n\n> On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior\n> wrote:\n>> # git rebase origin/master\n>> ...\n>> Applying: commitX\n>> Applying: commitY\n>> Applying: commitZ\n>> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>>\n>> The first thing I did was to check whether the index.lock file existed,\n>> but it doesn't.\n>\n> What platform is this on? If Windows, I'm wondering if something (such\n> as a virus scanner) is holding the lock file open long enough to\n> prevent Git from actually deleting it (and perhaps Git doesn't notice\n> the failed deletion -- until the next time it tries to take the lock).\n\nThis is on GNU/Linux (Fedora 28, to be specific). I haven't had the\nchance to test this on other distros, unfortunately. And since it seems\nto be a race condition, it's kind of hard to perform tests that trigger\nthis.\n\nThanks,\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371233","messageId":"CACsJy8ANLkz=3cj1dAuHdUCkrgQzos=90EEG0n901o3QAp3PUQ@mail.gmail.com","threadId":"50712","inReplyTo":"87k1h55bx0.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-12T10:28:15Z","receivedAt":"2019-03-12T10:28:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n wrote:\n> This works without problems most of the time (well, usually there are\n> conflicts and all, but that's a burden I have to carry). However,\n> sometimes I notice that git fails with:\n>\n> # git rebase origin/master\n> ...\n> Applying: commitX\n> Applying: commitY\n> Applying: commitZ\n> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>\n> The first thing I did was to check whether the index.lock file existed,\n> but it doesn't.\n\nIs the output this clean? What I'm looking for is signs of automatic\ngarbage collection kicking in the middle of the rebase. Something like\n\"Auto packing the repository blah blah for optimum performance\".\n-- \nDuy\n"},{"id":"371271","messageId":"877ed459eh.fsf@sergiodj.net","threadId":"50712","inReplyTo":"CACsJy8ANLkz=3cj1dAuHdUCkrgQzos=90EEG0n901o3QAp3PUQ@mail.gmail.com","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-12T16:45:26Z","receivedAt":"2019-03-12T16:45:31Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Tuesday, March 12 2019, Duy Nguyen wrote:\n\n> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n> wrote:\n>> This works without problems most of the time (well, usually there are\n>> conflicts and all, but that's a burden I have to carry). However,\n>> sometimes I notice that git fails with:\n>>\n>> # git rebase origin/master\n>> ...\n>> Applying: commitX\n>> Applying: commitY\n>> Applying: commitZ\n>> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>>\n>> The first thing I did was to check whether the index.lock file existed,\n>> but it doesn't.\n>\n> Is the output this clean? What I'm looking for is signs of automatic\n> garbage collection kicking in the middle of the rebase. Something like\n> \"Auto packing the repository blah blah for optimum performance\".\n\nYeah, this is the exact output. I also thought about \"git gc\", but I\ndon't see any output related to it. Is it possible that it's being\nexecuted in the background and not printing anything?\n\nThanks,\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371291","messageId":"CABPp-BFnxhiXfvZUZndD-_htMEw0bZzrLRFpAF9u5YV3wi6qnA@mail.gmail.com","threadId":"50712","inReplyTo":"877ed459eh.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-12T19:23:09Z","receivedAt":"2019-03-12T19:23:23Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n wrote:\n> On Tuesday, March 12 2019, Duy Nguyen wrote:\n>\n> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n> > wrote:\n> >> This works without problems most of the time (well, usually there are\n> >> conflicts and all, but that's a burden I have to carry). However,\n> >> sometimes I notice that git fails with:\n> >>\n> >> # git rebase origin/master\n> >> ...\n> >> Applying: commitX\n> >> Applying: commitY\n> >> Applying: commitZ\n> >> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n> >>\n> >> The first thing I did was to check whether the index.lock file existed,\n> >> but it doesn't.\n> >\n> > Is the output this clean? What I'm looking for is signs of automatic\n> > garbage collection kicking in the middle of the rebase. Something like\n> > \"Auto packing the repository blah blah for optimum performance\".\n>\n> Yeah, this is the exact output. I also thought about \"git gc\", but I\n> don't see any output related to it. Is it possible that it's being\n> executed in the background and not printing anything?\n\nAny chance you have a cronjob or other task execution mechanism that\nis running git commands in various directories (even simple commands\nlike 'git status' since it's not read-only contrary to what some\nexpect, or 'git fetch' which might trigger a background gc)?\n"},{"id":"371292","messageId":"8736nr6g94.fsf@sergiodj.net","threadId":"50712","inReplyTo":"CABPp-BFnxhiXfvZUZndD-_htMEw0bZzrLRFpAF9u5YV3wi6qnA@mail.gmail.com","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-12T19:32:07Z","receivedAt":"2019-03-12T19:32:11Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Tuesday, March 12 2019, Elijah Newren wrote:\n\n> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n> wrote:\n>> On Tuesday, March 12 2019, Duy Nguyen wrote:\n>>\n>> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n>> > wrote:\n>> >> This works without problems most of the time (well, usually there are\n>> >> conflicts and all, but that's a burden I have to carry). However,\n>> >> sometimes I notice that git fails with:\n>> >>\n>> >> # git rebase origin/master\n>> >> ...\n>> >> Applying: commitX\n>> >> Applying: commitY\n>> >> Applying: commitZ\n>> >> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>> >>\n>> >> The first thing I did was to check whether the index.lock file existed,\n>> >> but it doesn't.\n>> >\n>> > Is the output this clean? What I'm looking for is signs of automatic\n>> > garbage collection kicking in the middle of the rebase. Something like\n>> > \"Auto packing the repository blah blah for optimum performance\".\n>>\n>> Yeah, this is the exact output. I also thought about \"git gc\", but I\n>> don't see any output related to it. Is it possible that it's being\n>> executed in the background and not printing anything?\n>\n> Any chance you have a cronjob or other task execution mechanism that\n> is running git commands in various directories (even simple commands\n> like 'git status' since it's not read-only contrary to what some\n> expect, or 'git fetch' which might trigger a background gc)?\n\nNope, nothing like this. AFAIK, nothing is touching that repository at\nthe same time that I am. Besides, even if I wait some minutes before\ntrying again, the bug manifests again.\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371293","messageId":"CABPp-BH2k2yz-MrEvN2dX1jLVJydxOBv-bu-H5M_SXO_aLK8hw@mail.gmail.com","threadId":"50712","inReplyTo":"8736nr6g94.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-12T19:39:04Z","receivedAt":"2019-03-12T19:39:19Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior\n wrote:\n>\n> On Tuesday, March 12 2019, Elijah Newren wrote:\n>\n> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n> > wrote:\n> >> On Tuesday, March 12 2019, Duy Nguyen wrote:\n> >>\n> >> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n> >> > wrote:\n> >> >> This works without problems most of the time (well, usually there are\n> >> >> conflicts and all, but that's a burden I have to carry). However,\n> >> >> sometimes I notice that git fails with:\n> >> >>\n> >> >> # git rebase origin/master\n> >> >> ...\n> >> >> Applying: commitX\n> >> >> Applying: commitY\n> >> >> Applying: commitZ\n> >> >> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n> >> >>\n> >> >> The first thing I did was to check whether the index.lock file existed,\n> >> >> but it doesn't.\n> >> >\n> >> > Is the output this clean? What I'm looking for is signs of automatic\n> >> > garbage collection kicking in the middle of the rebase. Something like\n> >> > \"Auto packing the repository blah blah for optimum performance\".\n> >>\n> >> Yeah, this is the exact output. I also thought about \"git gc\", but I\n> >> don't see any output related to it. Is it possible that it's being\n> >> executed in the background and not printing anything?\n> >\n> > Any chance you have a cronjob or other task execution mechanism that\n> > is running git commands in various directories (even simple commands\n> > like 'git status' since it's not read-only contrary to what some\n> > expect, or 'git fetch' which might trigger a background gc)?\n>\n> Nope, nothing like this. AFAIK, nothing is touching that repository at\n> the same time that I am. Besides, even if I wait some minutes before\n> trying again, the bug manifests again.\n\nWell, even though you didn't see the output Duy was looking for, if\nyou set gc.auto to 0 and gc.autoPackLimit to 0 (and maybe\ngc.autoDetach to false just for good measure), does the problem still\noccur?\n"},{"id":"371294","messageId":"87y35j50hb.fsf@sergiodj.net","threadId":"50712","inReplyTo":"CABPp-BH2k2yz-MrEvN2dX1jLVJydxOBv-bu-H5M_SXO_aLK8hw@mail.gmail.com","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-12T19:58:08Z","receivedAt":"2019-03-12T19:58:12Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Tuesday, March 12 2019, Elijah Newren wrote:\n\n> On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior\n> wrote:\n>>\n>> On Tuesday, March 12 2019, Elijah Newren wrote:\n>>\n>> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n>> > wrote:\n>> >> On Tuesday, March 12 2019, Duy Nguyen wrote:\n>> >>\n>> >> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n>> >> > wrote:\n>> >> >> This works without problems most of the time (well, usually there are\n>> >> >> conflicts and all, but that's a burden I have to carry). However,\n>> >> >> sometimes I notice that git fails with:\n>> >> >>\n>> >> >> # git rebase origin/master\n>> >> >> ...\n>> >> >> Applying: commitX\n>> >> >> Applying: commitY\n>> >> >> Applying: commitZ\n>> >> >> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>> >> >>\n>> >> >> The first thing I did was to check whether the index.lock file existed,\n>> >> >> but it doesn't.\n>> >> >\n>> >> > Is the output this clean? What I'm looking for is signs of automatic\n>> >> > garbage collection kicking in the middle of the rebase. Something like\n>> >> > \"Auto packing the repository blah blah for optimum performance\".\n>> >>\n>> >> Yeah, this is the exact output. I also thought about \"git gc\", but I\n>> >> don't see any output related to it. Is it possible that it's being\n>> >> executed in the background and not printing anything?\n>> >\n>> > Any chance you have a cronjob or other task execution mechanism that\n>> > is running git commands in various directories (even simple commands\n>> > like 'git status' since it's not read-only contrary to what some\n>> > expect, or 'git fetch' which might trigger a background gc)?\n>>\n>> Nope, nothing like this. AFAIK, nothing is touching that repository at\n>> the same time that I am. Besides, even if I wait some minutes before\n>> trying again, the bug manifests again.\n>\n> Well, even though you didn't see the output Duy was looking for, if\n> you set gc.auto to 0 and gc.autoPackLimit to 0 (and maybe\n> gc.autoDetach to false just for good measure), does the problem still\n> occur?\n\nThanks, I was indeed going to try this. I'll test when I have time, and\nwill let you know.\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371397","messageId":"e0e1e159-844d-c9bf-e1cc-ada05384ef76@gmail.com","threadId":"50712","inReplyTo":"8736nr6g94.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-03-13T20:40:32Z","receivedAt":"2019-03-13T20:40:38Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Sergio\n\nOn 12/03/2019 19:32, Sergio Durigan Junior wrote:\n> On Tuesday, March 12 2019, Elijah Newren wrote:\n> \n>> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n>> wrote:\n>>> On Tuesday, March 12 2019, Duy Nguyen wrote:\n>>>\n>>>> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n>>>> wrote:\n>>>>> This works without problems most of the time (well, usually there are\n>>>>> conflicts and all, but that's a burden I have to carry). However,\n>>>>> sometimes I notice that git fails with:\n>>>>>\n>>>>> # git rebase origin/master\n>>>>> ...\n>>>>> Applying: commitX\n>>>>> Applying: commitY\n>>>>> Applying: commitZ\n>>>>> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>>>>>\n>>>>> The first thing I did was to check whether the index.lock file existed,\n>>>>> but it doesn't.\n>>>>\n>>>> Is the output this clean? What I'm looking for is signs of automatic\n>>>> garbage collection kicking in the middle of the rebase. Something like\n>>>> \"Auto packing the repository blah blah for optimum performance\".\n>>>\n>>> Yeah, this is the exact output. I also thought about \"git gc\", but I\n>>> don't see any output related to it. Is it possible that it's being\n>>> executed in the background and not printing anything?\n>>\n>> Any chance you have a cronjob or other task execution mechanism that\n>> is running git commands in various directories (even simple commands\n>> like 'git status' since it's not read-only contrary to what some\n>> expect, or 'git fetch' which might trigger a background gc)?\n> \n> Nope, nothing like this. AFAIK, nothing is touching that repository at\n> the same time that I am. Besides, even if I wait some minutes before\n> trying again, the bug manifests again.\n> \n\nDo you have any of the files in the repository open in an editor or ide \nwhile you are rebasing? I have seen this message when rebasing and one \nof the files is open in emacs which runs git status when it sees a file \nhas changed which locks the index while the rebase is running.\n\nBest Wishes\n\nPhillip\n"},{"id":"371399","messageId":"87pnqu4i1n.fsf@sergiodj.net","threadId":"50712","inReplyTo":"e0e1e159-844d-c9bf-e1cc-ada05384ef76@gmail.com","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-13T20:48:36Z","receivedAt":"2019-03-13T20:48:43Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Wednesday, March 13 2019, Phillip Wood wrote:\n\n> Hi Sergio\n>\n> On 12/03/2019 19:32, Sergio Durigan Junior wrote:\n>> On Tuesday, March 12 2019, Elijah Newren wrote:\n>>\n>>> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior\n>>> wrote:\n>>>> On Tuesday, March 12 2019, Duy Nguyen wrote:\n>>>>\n>>>>> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior\n>>>>> wrote:\n>>>>>> This works without problems most of the time (well, usually there are\n>>>>>> conflicts and all, but that's a burden I have to carry). However,\n>>>>>> sometimes I notice that git fails with:\n>>>>>>\n>>>>>> # git rebase origin/master\n>>>>>> ...\n>>>>>> Applying: commitX\n>>>>>> Applying: commitY\n>>>>>> Applying: commitZ\n>>>>>> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.\n>>>>>>\n>>>>>> The first thing I did was to check whether the index.lock file existed,\n>>>>>> but it doesn't.\n>>>>>\n>>>>> Is the output this clean? What I'm looking for is signs of automatic\n>>>>> garbage collection kicking in the middle of the rebase. Something like\n>>>>> \"Auto packing the repository blah blah for optimum performance\".\n>>>>\n>>>> Yeah, this is the exact output. I also thought about \"git gc\", but I\n>>>> don't see any output related to it. Is it possible that it's being\n>>>> executed in the background and not printing anything?\n>>>\n>>> Any chance you have a cronjob or other task execution mechanism that\n>>> is running git commands in various directories (even simple commands\n>>> like 'git status' since it's not read-only contrary to what some\n>>> expect, or 'git fetch' which might trigger a background gc)?\n>>\n>> Nope, nothing like this. AFAIK, nothing is touching that repository at\n>> the same time that I am. Besides, even if I wait some minutes before\n>> trying again, the bug manifests again.\n>>\n>\n> Do you have any of the files in the repository open in an editor or\n> ide while you are rebasing? I have seen this message when rebasing and\n> one of the files is open in emacs which runs git status when it sees a\n> file has changed which locks the index while the rebase is running.\n\nHey Phillip,\n\nHuh, I do have some of the files opened in Emacs! They're in\nbackground, but indeed, now that you mentioned I remember that Emacs\nkeeps track of changes and invokes \"git status\" sometimes. Next time I\nsee the bug, I'll try closing the files and see if it happens again.\n\nThanks for the insight!\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"371402","messageId":"20190313205926.GB5397@sigill.intra.peff.net","threadId":"50712","inReplyTo":"87pnqu4i1n.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-13T20:59:26Z","receivedAt":"2019-03-13T21:00:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 13, 2019 at 04:48:36PM -0400, Sergio Durigan Junior wrote:\n\n> Huh, I do have some of the files opened in Emacs! They're in\n> background, but indeed, now that you mentioned I remember that Emacs\n> keeps track of changes and invokes \"git status\" sometimes. Next time I\n> see the bug, I'll try closing the files and see if it happens again.\n\nIf Emacs (I guess maybe magit?) is running \"git status\" behind the\nscenes, you might benefit from teaching it to use \"git\n--no-optional-locks status\" instead. See the section \"BACKGROUND\nREFRESH\" in \"git help status\" for more discussion.\n\n-Peff\n"},{"id":"371404","messageId":"87lg1i4h6g.fsf@sergiodj.net","threadId":"50712","inReplyTo":"20190313205926.GB5397@sigill.intra.peff.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock","fromName":"Sergio Durigan Junior","fromEmail":"sergiodj@sergiodj.net","sentAt":"2019-03-13T21:07:19Z","receivedAt":"2019-03-13T21:07:30Z","isPatch":false,"sender":{"key":"sergiodj@sergiodj.net","avatar":null},"body":"On Wednesday, March 13 2019, Jeff King wrote:\n\n> On Wed, Mar 13, 2019 at 04:48:36PM -0400, Sergio Durigan Junior wrote:\n>\n>> Huh, I do have some of the files opened in Emacs! They're in\n>> background, but indeed, now that you mentioned I remember that Emacs\n>> keeps track of changes and invokes \"git status\" sometimes. Next time I\n>> see the bug, I'll try closing the files and see if it happens again.\n>\n> If Emacs (I guess maybe magit?) is running \"git status\" behind the\n> scenes, you might benefit from teaching it to use \"git\n> --no-optional-locks status\" instead. See the section \"BACKGROUND\n> REFRESH\" in \"git help status\" for more discussion.\n\nThanks Jeff. That's going to be helpful.\n\n-- \nSergio\nGPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36\nPlease send encrypted e-mail if possible\nhttp://sergiodj.net/\n"},{"id":"465962","messageId":"20221028160451.2040-1-alexander_sergey@mail.ru","threadId":"50712","inReplyTo":"87lg1i4h6g.fsf@sergiodj.net","subject":"Re: Possible race condition with git-rebase + .git/index.lock - probably a gettext issue","fromName":"Mingun","fromEmail":"alexander_sergey@mail.ru","sentAt":"2022-10-28T16:04:51Z","receivedAt":"2022-10-28T17:35:43Z","isPatch":false,"sender":{"key":"alexander_sergey@mail.ru","avatar":null},"body":"---\nIt seems that this bug is related to localization library, similar to this diesel issue: https://github.com/diesel-rs/diesel/discussions/2947#discussioncomment-2025857.\n\nAlso, this bug is highly depend on the free space capacity on a drive where working copy is located. I encounter this bug each time when my ssd is nearly full (about 6 GB of free space on 120 GB drive).\n\nAbout 90% of time, when I try to use `git svn rebase` in such conditions, the operation failed:\n\n```\n$ git svn rebase\nwarning: пропущен уже применённый коммит ef0998895a6\nwarning: пропущен уже применённый коммит d1dbbd6ef8b\nподсказка: use --reapply-cherry-picks to include skipped commits\nподсказка: Disable this message with \"git config advice.skippedCherryPicks false\"\nfatal: Не удалось создать «/path/to/my/git/repo/.git/index.lock»: Файл существует.\n\nПохоже, что другой процесс git запущен в этом репозитории,\nнапример редактор открыт из «git commit». Пожалуйста, убедитесь,\nчто все процессы были завершены и потом попробуйте снова.\nЕсли это не поможет, то возможно процесс git был ранее завершен\nс ошибкой в этом репозитории:\nудалите файл вручную для продолжения.\nrebase refs/remotes/origin/trunk: command returned error: 128\n\nВетка push удалена (была 5c2212d372e).\n$ git rebase --continue\nfatal: не удалось прочитать файл журнала «.git/rebase-merge/message»: Нет такого файла или каталога\n```\n\nAt the same time, when after I free space on my drive or set \"C\" locale, the operation is completed from first attempt.\n\nI hope this will help to localize and fix the issue."}]}