Re: [PATCH v6 0/5] teach submodules to know they're submodules

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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?