On Fri, Sep 22, 2017 at 2:25 PM, Jeff King <peff@xxxxxxxx> wrote: > 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@xxxxxxxx> 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@xxxxxxxxx/ 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
