From: Ævar Arnfjörð Bjarmason Date: Sat, 12 Feb 2022 20:35:48 GMT Subject: Re: [PATCH v6 0/5] teach submodules to know they're submodules Message-ID: <220212.864k53yfws.gmgdl@evledraar.gmail.com> In-Reply-To: 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 ). If that's the case we can walk up and ask parent .git's whether they think the 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?