Kévin Le Gouguec writes: >>> Eli Zaretskii 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? > > No clue thus far. You mention Git's automatic GC and that's one of my > scapegoats; another is vc-dir spawning more things than I realize. With the attached debugging patch (same as [1], plus binding vc-command-messages to t), I get these traces when the failure happens: Running 8 tests (2025-02-14 08:17:56+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))') passed 1/8 vc-git-test-annotate-time (0.002302 sec) Running in foreground: git --no-pager clone /tmp/emacs-test-go8R94-vc-git/ /tmp/emacs-test-NVSvcg-vc-git/ . Done (status=0): git --no-pager clone /tmp/emacs-test-go8R94-vc-git/ /tmp/emacs-test-NVSvcg-vc-git/ . Running in foreground: git --no-pager config --get remote.origin.url Done (status=0): git --no-pager config --get remote.origin.url Running in background: git --no-pager update-index --refresh . Done in background: git --no-pager update-index --refresh . Running in background: git --no-pager diff-index --relative -z -M HEAD -- . Done in background: git --no-pager diff-index --relative -z -M HEAD -- . Running in background: git --no-pager ls-files -z -u -- . Done in background: git --no-pager ls-files -z -u -- . Running in background: git --no-pager ls-files -z -o --exclude-standard -- . Done in background: git --no-pager ls-files -z -o --exclude-standard -- . Paused 1 time(s) waiting for vc-dir-busy Running in foreground: git --no-pager config --get remote.origin.url Done (status=0): git --no-pager config --get remote.origin.url Running in background: git --no-pager update-index --refresh . Running in foreground: git --no-pager checkout -b feature/foo master . err in /tmp/emacs-test-NVSvcg-vc-git/: (error Failed (status 128): git --no-pager checkout -b feature/foo master .) (buffer-string: fatal: Unable to create '/tmp/emacs-test-NVSvcg-vc-git/.git/index.lock': File exists. Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. ) Looking at vc-dir-refresh (invoked from vc-dir-revert-buffer-function, invoked by the testcase reverting the vc-dir buffer), I'd conclude that the sequence of events is (lighting a candle to the Muse of Manual Whitespace Adjustment; citing evidence with "> TRACES") * vc-git-test--dir-headers * revert-buffer * vc-dir-refresh * vc-dir-headers * vc-git-dir-extra-headers (👈 the code under test) > Running in foreground: git --no-pager config --get remote.origin.url > Done (status=0): git --no-pager config --get remote.origin.url * "asynchronous-looking things" > Running in background: git --no-pager update-index --refresh . (⚠️ no proof of termination) * vc-git-test--run "checkout" "-b" "feature/foo" main-branch * vc-git-test--wait (lambda () (file-exists-p ".git/index.lock")) > 🦗 [no log, ergo no lock file detected] * vc-git-command > Running in foreground: git --no-pager checkout -b feature/foo master . (⚠️ presumably the concurrent locking happens around here) > fatal: Unable to create '/tmp/emacs-test-NVSvcg-vc-git/.git/index.lock': File exists. I think 'git update-index' is a good suspect: cursory glance at builtin/update-index.c:cmd_update_index confirms that it unconditionally does: newfd = repo_hold_locked_index(the_repository, &lock_file, 0); Bottomline: * maybe we could amend the testcase to sync with this background command, * unclear whether we should; barring fault in my logic, I stand by my opinion in [2] and would prefer to install the patch in that message, on the grounds that contending with vc-dir's asynchrony is outside the scope of this test (to wit: testing the extra-headers logic). [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76187#35 [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76187#53