git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* Possible race condition with git-rebase + .git/index.lock
@ 2019-03-11 21:38 Sergio Durigan Junior
  2019-03-11 22:50 ` Eric Sunshine
  2019-03-12 10:28 ` Duy Nguyen
  0 siblings, 2 replies; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-11 21:38 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

Hi there,

I've been bit by this bug many times, and always forget to report it
here, but this time I finally remembered.

The scenario is this:

- I have a local repository which tracks the upstream of the project.

- I have 120+ local commits.

- Every week or so, I have to rebase my local commits on top of
  upstream's origin/master.

The workflow is simple:

  # git fetch origin && git rebase origin/master

This works without problems most of the time (well, usually there are
conflicts and all, but that's a burden I have to carry).  However,
sometimes I notice that git fails with:

  # git rebase origin/master
  ...
  Applying: commitX
  Applying: commitY
  Applying: commitZ
  fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.

The first thing I did was to check whether the index.lock file existed,
but it doesn't.

I also I thought it might have something to do with "commitZ", but after
I ran "git rebase --abort" and tried rebasing again, I noticed that it
would stop at another commit.

This seems like a race condition, but after inspecting builtin/rebase.c
it doesn't seem like the "git am" commands are run in parallel (and it
wouldn't make sense if they did, anyway).

I tried using GIT_TRACE, but haven't seen any useful information in the
logs.  I tried using the "next" branch, and found that the problem
exists there as well.  I wonder if anyone else has seen this problem.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-11 21:38 Possible race condition with git-rebase + .git/index.lock Sergio Durigan Junior
@ 2019-03-11 22:50 ` Eric Sunshine
  2019-03-11 22:53   ` Sergio Durigan Junior
  2019-03-12 10:28 ` Duy Nguyen
  1 sibling, 1 reply; 13+ messages in thread
From: Eric Sunshine @ 2019-03-11 22:50 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: Git List

On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior
<sergiodj@sergiodj.net> wrote:
>   # git rebase origin/master
>   ...
>   Applying: commitX
>   Applying: commitY
>   Applying: commitZ
>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>
> The first thing I did was to check whether the index.lock file existed,
> but it doesn't.

What platform is this on? If Windows, I'm wondering if something (such
as a virus scanner) is holding the lock file open long enough to
prevent Git from actually deleting it (and perhaps Git doesn't notice
the failed deletion -- until the next time it tries to take the lock).

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-11 22:50 ` Eric Sunshine
@ 2019-03-11 22:53   ` Sergio Durigan Junior
  0 siblings, 0 replies; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-11 22:53 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: Git List

On Monday, March 11 2019, Eric Sunshine wrote:

> On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior
> <sergiodj@sergiodj.net> wrote:
>>   # git rebase origin/master
>>   ...
>>   Applying: commitX
>>   Applying: commitY
>>   Applying: commitZ
>>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>>
>> The first thing I did was to check whether the index.lock file existed,
>> but it doesn't.
>
> What platform is this on? If Windows, I'm wondering if something (such
> as a virus scanner) is holding the lock file open long enough to
> prevent Git from actually deleting it (and perhaps Git doesn't notice
> the failed deletion -- until the next time it tries to take the lock).

This is on GNU/Linux (Fedora 28, to be specific).  I haven't had the
chance to test this on other distros, unfortunately.  And since it seems
to be a race condition, it's kind of hard to perform tests that trigger
this.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-11 21:38 Possible race condition with git-rebase + .git/index.lock Sergio Durigan Junior
  2019-03-11 22:50 ` Eric Sunshine
@ 2019-03-12 10:28 ` Duy Nguyen
  2019-03-12 16:45   ` Sergio Durigan Junior
  1 sibling, 1 reply; 13+ messages in thread
From: Duy Nguyen @ 2019-03-12 10:28 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: Git Mailing List

On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
<sergiodj@sergiodj.net> wrote:
> This works without problems most of the time (well, usually there are
> conflicts and all, but that's a burden I have to carry).  However,
> sometimes I notice that git fails with:
>
>   # git rebase origin/master
>   ...
>   Applying: commitX
>   Applying: commitY
>   Applying: commitZ
>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>
> The first thing I did was to check whether the index.lock file existed,
> but it doesn't.

Is the output this clean? What I'm looking for is signs of automatic
garbage collection kicking in the middle of the rebase. Something like
"Auto packing the repository blah blah for optimum performance".
-- 
Duy

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 10:28 ` Duy Nguyen
@ 2019-03-12 16:45   ` Sergio Durigan Junior
  2019-03-12 19:23     ` Elijah Newren
  0 siblings, 1 reply; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-12 16:45 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Git Mailing List

On Tuesday, March 12 2019, Duy Nguyen wrote:

> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> <sergiodj@sergiodj.net> wrote:
>> This works without problems most of the time (well, usually there are
>> conflicts and all, but that's a burden I have to carry).  However,
>> sometimes I notice that git fails with:
>>
>>   # git rebase origin/master
>>   ...
>>   Applying: commitX
>>   Applying: commitY
>>   Applying: commitZ
>>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>>
>> The first thing I did was to check whether the index.lock file existed,
>> but it doesn't.
>
> Is the output this clean? What I'm looking for is signs of automatic
> garbage collection kicking in the middle of the rebase. Something like
> "Auto packing the repository blah blah for optimum performance".

Yeah, this is the exact output.  I also thought about "git gc", but I
don't see any output related to it.  Is it possible that it's being
executed in the background and not printing anything?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 16:45   ` Sergio Durigan Junior
@ 2019-03-12 19:23     ` Elijah Newren
  2019-03-12 19:32       ` Sergio Durigan Junior
  0 siblings, 1 reply; 13+ messages in thread
From: Elijah Newren @ 2019-03-12 19:23 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: Duy Nguyen, Git Mailing List

On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
<sergiodj@sergiodj.net> wrote:
> On Tuesday, March 12 2019, Duy Nguyen wrote:
>
> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> > <sergiodj@sergiodj.net> wrote:
> >> This works without problems most of the time (well, usually there are
> >> conflicts and all, but that's a burden I have to carry).  However,
> >> sometimes I notice that git fails with:
> >>
> >>   # git rebase origin/master
> >>   ...
> >>   Applying: commitX
> >>   Applying: commitY
> >>   Applying: commitZ
> >>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
> >>
> >> The first thing I did was to check whether the index.lock file existed,
> >> but it doesn't.
> >
> > Is the output this clean? What I'm looking for is signs of automatic
> > garbage collection kicking in the middle of the rebase. Something like
> > "Auto packing the repository blah blah for optimum performance".
>
> Yeah, this is the exact output.  I also thought about "git gc", but I
> don't see any output related to it.  Is it possible that it's being
> executed in the background and not printing anything?

Any chance you have a cronjob or other task execution mechanism that
is running git commands in various directories (even simple commands
like 'git status' since it's not read-only contrary to what some
expect, or 'git fetch' which might trigger a background gc)?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 19:23     ` Elijah Newren
@ 2019-03-12 19:32       ` Sergio Durigan Junior
  2019-03-12 19:39         ` Elijah Newren
  2019-03-13 20:40         ` Phillip Wood
  0 siblings, 2 replies; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-12 19:32 UTC (permalink / raw)
  To: Elijah Newren; +Cc: Duy Nguyen, Git Mailing List

On Tuesday, March 12 2019, Elijah Newren wrote:

> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
> <sergiodj@sergiodj.net> wrote:
>> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>
>> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>> > <sergiodj@sergiodj.net> wrote:
>> >> This works without problems most of the time (well, usually there are
>> >> conflicts and all, but that's a burden I have to carry).  However,
>> >> sometimes I notice that git fails with:
>> >>
>> >>   # git rebase origin/master
>> >>   ...
>> >>   Applying: commitX
>> >>   Applying: commitY
>> >>   Applying: commitZ
>> >>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>> >>
>> >> The first thing I did was to check whether the index.lock file existed,
>> >> but it doesn't.
>> >
>> > Is the output this clean? What I'm looking for is signs of automatic
>> > garbage collection kicking in the middle of the rebase. Something like
>> > "Auto packing the repository blah blah for optimum performance".
>>
>> Yeah, this is the exact output.  I also thought about "git gc", but I
>> don't see any output related to it.  Is it possible that it's being
>> executed in the background and not printing anything?
>
> Any chance you have a cronjob or other task execution mechanism that
> is running git commands in various directories (even simple commands
> like 'git status' since it's not read-only contrary to what some
> expect, or 'git fetch' which might trigger a background gc)?

Nope, nothing like this.  AFAIK, nothing is touching that repository at
the same time that I am.  Besides, even if I wait some minutes before
trying again, the bug manifests again.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 19:32       ` Sergio Durigan Junior
@ 2019-03-12 19:39         ` Elijah Newren
  2019-03-12 19:58           ` Sergio Durigan Junior
  2019-03-13 20:40         ` Phillip Wood
  1 sibling, 1 reply; 13+ messages in thread
From: Elijah Newren @ 2019-03-12 19:39 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: Duy Nguyen, Git Mailing List

On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior
<sergiodj@sergiodj.net> wrote:
>
> On Tuesday, March 12 2019, Elijah Newren wrote:
>
> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
> > <sergiodj@sergiodj.net> wrote:
> >> On Tuesday, March 12 2019, Duy Nguyen wrote:
> >>
> >> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> >> > <sergiodj@sergiodj.net> wrote:
> >> >> This works without problems most of the time (well, usually there are
> >> >> conflicts and all, but that's a burden I have to carry).  However,
> >> >> sometimes I notice that git fails with:
> >> >>
> >> >>   # git rebase origin/master
> >> >>   ...
> >> >>   Applying: commitX
> >> >>   Applying: commitY
> >> >>   Applying: commitZ
> >> >>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
> >> >>
> >> >> The first thing I did was to check whether the index.lock file existed,
> >> >> but it doesn't.
> >> >
> >> > Is the output this clean? What I'm looking for is signs of automatic
> >> > garbage collection kicking in the middle of the rebase. Something like
> >> > "Auto packing the repository blah blah for optimum performance".
> >>
> >> Yeah, this is the exact output.  I also thought about "git gc", but I
> >> don't see any output related to it.  Is it possible that it's being
> >> executed in the background and not printing anything?
> >
> > Any chance you have a cronjob or other task execution mechanism that
> > is running git commands in various directories (even simple commands
> > like 'git status' since it's not read-only contrary to what some
> > expect, or 'git fetch' which might trigger a background gc)?
>
> Nope, nothing like this.  AFAIK, nothing is touching that repository at
> the same time that I am.  Besides, even if I wait some minutes before
> trying again, the bug manifests again.

Well, even though you didn't see the output Duy was looking for, if
you set gc.auto to 0 and gc.autoPackLimit to 0 (and maybe
gc.autoDetach to false just for good measure), does the problem still
occur?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 19:39         ` Elijah Newren
@ 2019-03-12 19:58           ` Sergio Durigan Junior
  0 siblings, 0 replies; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-12 19:58 UTC (permalink / raw)
  To: Elijah Newren; +Cc: Duy Nguyen, Git Mailing List

On Tuesday, March 12 2019, Elijah Newren wrote:

> On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior
> <sergiodj@sergiodj.net> wrote:
>>
>> On Tuesday, March 12 2019, Elijah Newren wrote:
>>
>> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
>> > <sergiodj@sergiodj.net> wrote:
>> >> On Tuesday, March 12 2019, Duy Nguyen wrote:
>> >>
>> >> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>> >> > <sergiodj@sergiodj.net> wrote:
>> >> >> This works without problems most of the time (well, usually there are
>> >> >> conflicts and all, but that's a burden I have to carry).  However,
>> >> >> sometimes I notice that git fails with:
>> >> >>
>> >> >>   # git rebase origin/master
>> >> >>   ...
>> >> >>   Applying: commitX
>> >> >>   Applying: commitY
>> >> >>   Applying: commitZ
>> >> >>   fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>> >> >>
>> >> >> The first thing I did was to check whether the index.lock file existed,
>> >> >> but it doesn't.
>> >> >
>> >> > Is the output this clean? What I'm looking for is signs of automatic
>> >> > garbage collection kicking in the middle of the rebase. Something like
>> >> > "Auto packing the repository blah blah for optimum performance".
>> >>
>> >> Yeah, this is the exact output.  I also thought about "git gc", but I
>> >> don't see any output related to it.  Is it possible that it's being
>> >> executed in the background and not printing anything?
>> >
>> > Any chance you have a cronjob or other task execution mechanism that
>> > is running git commands in various directories (even simple commands
>> > like 'git status' since it's not read-only contrary to what some
>> > expect, or 'git fetch' which might trigger a background gc)?
>>
>> Nope, nothing like this.  AFAIK, nothing is touching that repository at
>> the same time that I am.  Besides, even if I wait some minutes before
>> trying again, the bug manifests again.
>
> Well, even though you didn't see the output Duy was looking for, if
> you set gc.auto to 0 and gc.autoPackLimit to 0 (and maybe
> gc.autoDetach to false just for good measure), does the problem still
> occur?

Thanks, I was indeed going to try this.  I'll test when I have time, and
will let you know.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-12 19:32       ` Sergio Durigan Junior
  2019-03-12 19:39         ` Elijah Newren
@ 2019-03-13 20:40         ` Phillip Wood
  2019-03-13 20:48           ` Sergio Durigan Junior
  1 sibling, 1 reply; 13+ messages in thread
From: Phillip Wood @ 2019-03-13 20:40 UTC (permalink / raw)
  To: Sergio Durigan Junior, Elijah Newren; +Cc: Duy Nguyen, Git Mailing List

Hi Sergio

On 12/03/2019 19:32, Sergio Durigan Junior wrote:
> On Tuesday, March 12 2019, Elijah Newren wrote:
> 
>> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
>> <sergiodj@sergiodj.net> wrote:
>>> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>>
>>>> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>>>> <sergiodj@sergiodj.net> wrote:
>>>>> This works without problems most of the time (well, usually there are
>>>>> conflicts and all, but that's a burden I have to carry).  However,
>>>>> sometimes I notice that git fails with:
>>>>>
>>>>>    # git rebase origin/master
>>>>>    ...
>>>>>    Applying: commitX
>>>>>    Applying: commitY
>>>>>    Applying: commitZ
>>>>>    fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>>>>>
>>>>> The first thing I did was to check whether the index.lock file existed,
>>>>> but it doesn't.
>>>>
>>>> Is the output this clean? What I'm looking for is signs of automatic
>>>> garbage collection kicking in the middle of the rebase. Something like
>>>> "Auto packing the repository blah blah for optimum performance".
>>>
>>> Yeah, this is the exact output.  I also thought about "git gc", but I
>>> don't see any output related to it.  Is it possible that it's being
>>> executed in the background and not printing anything?
>>
>> Any chance you have a cronjob or other task execution mechanism that
>> is running git commands in various directories (even simple commands
>> like 'git status' since it's not read-only contrary to what some
>> expect, or 'git fetch' which might trigger a background gc)?
> 
> Nope, nothing like this.  AFAIK, nothing is touching that repository at
> the same time that I am.  Besides, even if I wait some minutes before
> trying again, the bug manifests again.
> 

Do you have any of the files in the repository open in an editor or ide 
while you are rebasing? I have seen this message when rebasing and one 
of the files is open in emacs which runs git status when it sees a file 
has changed which locks the index while the rebase is running.

Best Wishes

Phillip

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-13 20:40         ` Phillip Wood
@ 2019-03-13 20:48           ` Sergio Durigan Junior
  2019-03-13 20:59             ` Jeff King
  0 siblings, 1 reply; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-13 20:48 UTC (permalink / raw)
  To: Phillip Wood; +Cc: Elijah Newren, phillip.wood, Duy Nguyen, Git Mailing List

On Wednesday, March 13 2019, Phillip Wood wrote:

> Hi Sergio
>
> On 12/03/2019 19:32, Sergio Durigan Junior wrote:
>> On Tuesday, March 12 2019, Elijah Newren wrote:
>>
>>> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
>>> <sergiodj@sergiodj.net> wrote:
>>>> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>>>
>>>>> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>>>>> <sergiodj@sergiodj.net> wrote:
>>>>>> This works without problems most of the time (well, usually there are
>>>>>> conflicts and all, but that's a burden I have to carry).  However,
>>>>>> sometimes I notice that git fails with:
>>>>>>
>>>>>>    # git rebase origin/master
>>>>>>    ...
>>>>>>    Applying: commitX
>>>>>>    Applying: commitY
>>>>>>    Applying: commitZ
>>>>>>    fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>>>>>>
>>>>>> The first thing I did was to check whether the index.lock file existed,
>>>>>> but it doesn't.
>>>>>
>>>>> Is the output this clean? What I'm looking for is signs of automatic
>>>>> garbage collection kicking in the middle of the rebase. Something like
>>>>> "Auto packing the repository blah blah for optimum performance".
>>>>
>>>> Yeah, this is the exact output.  I also thought about "git gc", but I
>>>> don't see any output related to it.  Is it possible that it's being
>>>> executed in the background and not printing anything?
>>>
>>> Any chance you have a cronjob or other task execution mechanism that
>>> is running git commands in various directories (even simple commands
>>> like 'git status' since it's not read-only contrary to what some
>>> expect, or 'git fetch' which might trigger a background gc)?
>>
>> Nope, nothing like this.  AFAIK, nothing is touching that repository at
>> the same time that I am.  Besides, even if I wait some minutes before
>> trying again, the bug manifests again.
>>
>
> Do you have any of the files in the repository open in an editor or
> ide while you are rebasing? I have seen this message when rebasing and
> one of the files is open in emacs which runs git status when it sees a
> file has changed which locks the index while the rebase is running.

Hey Phillip,

Huh, I do have some of the files opened in Emacs!  They're in
background, but indeed, now that you mentioned I remember that Emacs
keeps track of changes and invokes "git status" sometimes.  Next time I
see the bug, I'll try closing the files and see if it happens again.

Thanks for the insight!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-13 20:48           ` Sergio Durigan Junior
@ 2019-03-13 20:59             ` Jeff King
  2019-03-13 21:07               ` Sergio Durigan Junior
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff King @ 2019-03-13 20:59 UTC (permalink / raw)
  To: Sergio Durigan Junior
  Cc: Phillip Wood, Elijah Newren, phillip.wood, Duy Nguyen, Git Mailing List

On Wed, Mar 13, 2019 at 04:48:36PM -0400, Sergio Durigan Junior wrote:

> Huh, I do have some of the files opened in Emacs!  They're in
> background, but indeed, now that you mentioned I remember that Emacs
> keeps track of changes and invokes "git status" sometimes.  Next time I
> see the bug, I'll try closing the files and see if it happens again.

If Emacs (I guess maybe magit?) is running "git status" behind the
scenes, you might benefit from teaching it to use "git
--no-optional-locks status" instead. See the section "BACKGROUND
REFRESH" in "git help status" for more discussion.

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Possible race condition with git-rebase + .git/index.lock
  2019-03-13 20:59             ` Jeff King
@ 2019-03-13 21:07               ` Sergio Durigan Junior
  0 siblings, 0 replies; 13+ messages in thread
From: Sergio Durigan Junior @ 2019-03-13 21:07 UTC (permalink / raw)
  To: Jeff King
  Cc: Phillip Wood, Elijah Newren, phillip.wood, Duy Nguyen, Git Mailing List

On Wednesday, March 13 2019, Jeff King wrote:

> On Wed, Mar 13, 2019 at 04:48:36PM -0400, Sergio Durigan Junior wrote:
>
>> Huh, I do have some of the files opened in Emacs!  They're in
>> background, but indeed, now that you mentioned I remember that Emacs
>> keeps track of changes and invokes "git status" sometimes.  Next time I
>> see the bug, I'll try closing the files and see if it happens again.
>
> If Emacs (I guess maybe magit?) is running "git status" behind the
> scenes, you might benefit from teaching it to use "git
> --no-optional-locks status" instead. See the section "BACKGROUND
> REFRESH" in "git help status" for more discussion.

Thanks Jeff.  That's going to be helpful.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-03-13 21:07 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-11 21:38 Possible race condition with git-rebase + .git/index.lock Sergio Durigan Junior
2019-03-11 22:50 ` Eric Sunshine
2019-03-11 22:53   ` Sergio Durigan Junior
2019-03-12 10:28 ` Duy Nguyen
2019-03-12 16:45   ` Sergio Durigan Junior
2019-03-12 19:23     ` Elijah Newren
2019-03-12 19:32       ` Sergio Durigan Junior
2019-03-12 19:39         ` Elijah Newren
2019-03-12 19:58           ` Sergio Durigan Junior
2019-03-13 20:40         ` Phillip Wood
2019-03-13 20:48           ` Sergio Durigan Junior
2019-03-13 20:59             ` Jeff King
2019-03-13 21:07               ` Sergio Durigan Junior

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git