Subject: Re: bug#76187: vc-git-test-dir-branch-headers failure on Fedora

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Feb 2025 22:44:32 +0200

> From: Kévin Le Gouguec <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Thu, 13 Feb 2025 19:23:15 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > How about just ignoring the error in this case?  AFAIU, it's rare
> > enough to not be important, right?  AFAIK, you cannot have more than
> > one Git instance modifying the repository at any given time, so this
> > problem cannot be fixed in principle if we are running tow or more Git
> > sessions in parallel.  IOW, these tests must NOT be run via parallel
> > make processing.
> 
> Apologies if my brain is too fried and I misunderstood: didn't I show
> that this error shows up without parallelism?

If that is true, it means _my_ brain is fried, but then how is that
other Git process invoked, and by whom?  IOW, which process locked the
repository exactly while we were running Git from the test?

> (a) checking for index.lock presence before invoking vc-git-command does
> not save us,
> (b) replacing vc-dir-kill-dir-status-process with a busy loop on
> vc-dir-busy does not save us either,
> (a+b) together do not save us either)

My suggestion was to ignore the error, not to do any of the above.
IOW, treat this test as if it were skipped, if this error happens.

> (If Git is responsible for that async process, then that change alone
> will not help, although the scaffolding simplification would still be
> nice TBH)

The only way I can think of that Git itself causes this is if the
automatic GC is invoked.  But AFAIR automatic GC doesn't lock the
repository, does it?  If it does, perhaps disabling GC for the
duration of the test will solve this?