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: 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. 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. Thanks and hope that helps, Jonathan > 4. https://lore.kernel.org/git/RFC-patch-2.2-b49d4c8db7d-20211117T113134Z-avarab@xxxxxxxxx/
