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

[Kévin Le Gouguec]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2/11/25 12:43, Kévin Le Gouguec wrote:
>> Another git process seems to be running in this repository,
>
> I guess the test won't work with "make -j check", since some other test might 
> also be running git in that repository. If my guess is right, to fix this you 
> can arrange for the test to run in a clone instead. Similarly for any other 
> test that might want to alter that repository or its working files.

The test does arrange to run in isolated directories, using
ert-with-temp-directory:

(defmacro vc-git-test--with-repo (name &rest body)
  ;; …
  `(ert-with-temp-directory ,name
     (let ((default-directory ,name)
           ;; …
           )
       (vc-create-repo 'Git)
       ,@body)))

(ert-deftest vc-git-test-dir-branch-headers ()
  ;; …
  ;; Create a repository that will serve as the "remote".
  (vc-git-test--with-repo origin-repo                                   
    (let ((main-branch (vc-git-test--start-branch)))
      ;; 'git clone' this repository and test things in this clone.
      (ert-with-temp-directory clone-repo
        ;; …
        ))))

So unless I am missing something, 'make -j' ought not be a factor.

My current working theories are:

a. We fail to sync with some asynchronous processes spawned by vc before
   running these 'git checkout' commands; there is precedent for
   synchronization problems:

     (defun vc-git-test--dir-headers (headers)
       "…"
       ;; FIXME: to reproduce interactive sessions faithfully, we would need
       ;; to wait for the dir-status-files process to terminate; have not
       ;; found a reliable way to do this.  As a workaround, kill pending
       ;; processes and revert the `vc-dir' buffer.
       (vc-dir-kill-dir-status-process)
       (revert-buffer)
       ;; …
       )

   FWIW, sticking one more speculative (vc-dir-kill-dir-status-process)
   after (revert-buffer) lowers the failure rate (took 10 minutes to
   reproduce it once; no second occurrence after >5k runs over 30min).

b. One of the test's git commands spawns a… background GC job or
   something, and the test's next git command trips over that.

I suppose either a or b would be solved by vc-git-test--run spinning for
a bit while (file-exists-p "…/index.lock"); ideally though I'd prefer to
catch the locking process red-handed… not sure how to achieve this
though.