Re: emacs-31 a9fc13614ec: Export GIT_OPTIONAL_LOCKS=0 for "git status" invocations (bug#80903)

> From: Sean Whitton <[email protected]>
> Cc: [email protected]
> Date: Sat, 01 Aug 2026 14:43:37 +0100
> 
> Eli Zaretskii [01/Aug  9:06am +03] wrote:
> >> From: [email protected]
> >> Date: Fri, 31 Jul 2026 12:00:15 -0400
> >>
> >> branch: emacs-31
> >> commit a9fc13614eca8aaa34d227b28c4c4d37b13212af
> >> Author: Sean Whitton <[email protected]>
> >> Commit: Sean Whitton <[email protected]>
> >>
> >>     Export GIT_OPTIONAL_LOCKS=0 for "git status" invocations (bug#80903)
> >>
> >>     * lisp/vc/vc-git.el (vc-git--env-vars): New function.
> >>     (vc-git-command, vc-git--call): Use it (bug#80903).
> >> ---
> >>  lisp/vc/vc-git.el | 39 +++++++++++++++++++--------------------
> >>  1 file changed, 19 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> >> index f336aae984d..17c358e25d5 100644
> >> --- a/lisp/vc/vc-git.el
> >> +++ b/lisp/vc/vc-git.el
> >> @@ -2884,6 +2884,21 @@ page for the meanings of these attributes."
> >>  
> >>  ;;; Internal commands
> >>
> >> +(defun vc-git--env-vars (subcommand)
> >> +  "Return env vars for the `process-environment' of Git processes."
> >> +  `("GIT_DIR"
> >> +    ,@(and vc-git-use-literal-pathspecs
> >> +           '("GIT_LITERAL_PATHSPECS=1"))
> >> +    ;; Avoid optional repository locking during background operations
> >> +    ;; (bug#21559, bug#80903).  Skipping these locks is always safe and
> >> +    ;; can only lead to subsequent commands running more slowly.
> >> +    ;; The "git status" case covers how `vc-checkin' uses
> >> +    ;; `vc-dir-resynch-file' to update the display state of files
> >> +    ;; undergoing an asynchronous check-in.
> >> +    ,@(and (or revert-buffer-in-progress
> >> +               (equal subcommand "status"))
> >> +           '("GIT_OPTIONAL_LOCKS=0"))))
> >
> > GIT_OPTIONAL_LOCKS is supported only since Git 2.15.  Would it be
> > possible to use the --no-optional-locks command-line option instead?
> 
> That would be a riskier change because setting an env var doesn't
> disrupt the rest of argument parsing, as compared with passing a new
> argument.

Sorry, I don't understand the problem you are describing.  Can you
elaborate about the "disruption"?

> Git 2.15 is almost nine years old.  Perhaps it's okay if asynchronous
> check-ins (an optional feature) occasionally fail due to a race?

It's okay to occasionally fail, but it's better not to, if we can do
that.  Obviously.