Re: [PATCH] git: add --no-optional-locks option

From: Stefan Beller <sbeller@google.com>
Date: Sep 22, 2017, 21:41 UTC
Message-ID: <CAGZ79kYJH-4qb5hiT1C_aCFXLcdiJs5h+Z7Goz4trp52C5s3Lw@mail.gmail.com>
In-Reply-To: <20170922212525.kxldygbjrmjqu7ci@sigill.intra.peff.net>

On Fri, Sep 22, 2017 at 2:25 PM, Jeff King <peff@peff.net> wrote:

Show 17 quoted lines

> On Fri, Sep 22, 2017 at 01:09:32PM -0700, Stefan Beller wrote:
>
>> On Thu, Sep 21, 2017 at 9:25 PM, Jeff King <peff@peff.net> wrote:
>>
>> >
>> > But imagine that "git status" learns to recurse into submodules and run
>> > "git status" inside them. Surely we would want the submodule repos to
>> > also avoid taking any unnecessary locks?
>>
>> You can teach Git to recurse into submodules already at home,
>> just 'git config status.submoduleSummary none'. ;)
>>
>> It occurs to me that the config name is badly choosen, as it stores
>> an argument for git status --ignore-submodules[=mode]
>
> Ah, thanks. I _thought_ we could already do that but when I went looking
> for the standard --recursive option I couldn't find it.

Thanks for checking for submodules there.

I personally prefer --recurse-submodules despite the longer name, because a plain recursive option can mean anything in a sufficiently complex program such as Git (recurse into the tree (c.f. ls-tree), or for the algorithm used (c.f. merge, diff) or yet another dimension I did not think of).

> So yes, I would think we would want this option to apply recursively in
> that case, even when we cross repository boundaries.

Regarding the actual patch which is heavily aimed at coping with IDEs despite the command line being used, I wonder how many IDEs pass --ignore-submodules and recurse themselves (if needed). Reason for my suspicion is [1] which does pay attention to submodules:

>    Our application calls status including the following flags:
>    --porcelain=v2 --ignored --untracked-files=all --ignore-submodules=none

[1] https://public-inbox.org/git/2bbb1d0f-ae06-1878-d185-112bd51f75c9@gmail.com/

There might be another option to cope with the situation:

 4. Teach all commands to spinlock / busywait shortly for important
     locks instead of giving up. In that case git-status rewriting
     the index ought to be fine?

Thanks, Stefan