On Mon, Feb 07 2022, Jonathan Nieder wrote: > Hi, > > Ævar Arnfjörð Bjarmason wrote: >> On Thu, Feb 03 2022, Emily Shaffer wrote: > >>> To be honest, I'm not all that interested in performance >>> - I want the config added for correctness, instead. >> >> And I'm honestly still at the point of not even being against this whole >> thing, although it probably sounds like that. I'm really not. >> >> I just genuinely don't get where this is headed. I.e. for the last >> iteration I did a demo patch on top that showed that there was no case >> added by the series where the on-the-fly discovery wasn't equivalent to >> the set-in-config value[4]. > > Here's a few examples: I've read the downthread, but it's probably best to reply to this... > 1. Suppose I track my $HOME directory as a git repository. Within my > home directory, I have a src/git/ subdirectory with a clone of > git.git, but I never intended to treat this as a submodule. > > If I run "git rev-parse --show-superproject-working-tree", then it > will discover my home directory repository, run ls-files in there > to see if it has GITLINK entries, and either see one for src/git if > I had "git add"ed it by mistake or not see one. In either case, > it would it would view my src/git/ directory as being a submodule > of my home directory even though I hadn't intended it to be so. > > 2. Suppose I have a copy of a repository such as > https://gerrit.googlesource.com/gerrit/, with all its submodules. > I am in the plugins/replication/ directory. > > If I run "git rev-parse --show-superproject-working-tree", then it > will discover my gerrit repository, run ls-files in there to see if > it has GITLINK entries, and use the result to decide whether the > cwd is a submodule. So for example, if I had run "git rm --cached > plugins/replication" to _prepare to_ remove the plugins/replication > submodule, then "git rev-parse --show-superproject-working-tree" > will produce the wrong result. These both seem like valid edge cases, but they're still going to be the same edge case on the "parent" side even with a proposed cache (whether it's a boolean or a path). I.e. the question here is really not one of caching, but of what it means for Y to be a submodule of X. I assumed that we'd prefer a 1=1 relationship between the parent reporting that Y is a submodule of it, and Y reporting that it is a submodule (of the parent at some <path>). If that's the case we can walk up and ask parent .git's whether they think the <path> is their submodule. If it's not the case perhaps a config is needed, but then that surely has wider implications. I.e. won't it be the case that we can't add the config after-the-fact as this series proposes in those some ambiguous cases?xo > 3. Suppose I am not using submodules at all. I have a clone of > mawk.git and I am working there. > > If I run "git rev-parse --show-superproject-working-tree", then I'm > presumably interested in doing something submodule-specific; > nothing wrong with that. But the series we're responding to is > meant to support a wider variety of operations --- for example, > suppose I am running a plain "git status" operation. > > If "git status" runs "git rev-parse > --show-superproject-working-tree", then git would walk up the > filesystem above my mawk/ directory, looking for another .git dir. > We can reach an NFS automounter directory and just hang. Even > without an NFS automounter, we'd expect this to take a while > because, unlike normal repository discovery, we have no reason to > believe that the walk is going to quickly discover a .git directory > and terminate. So this would violate user expectations. We have a /a/b/c/d.git mounted, but not a parent /a/b/, and walking upwards causes it to be mounted?
