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

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> 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.

I am not sure about this one.  If you added an unrelated one with
"git add" by mistake, you'd want to know about the mistake sooner
rather than later, no?

> 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.

Yes, looking only at the index of the superproject will have that
problem, but don't other things in the superproject point at the
submodule, too, e.g. submodule.<name>.* configuration variables?

And then, after removing them to truly dissociate the submodule from
the superproject, "git rev-parse --show-superproject-working-tree"
may stop saying that it is a submodule, but this series wants to
make it irrelevant what the command says.  Until you unset the
configuration variable in the submodule, it will stay to be a
submodule of the superproject, but the superproject no longer thinks
it is responsible for the submodule.  You'll have to deal with an
inconsistent state during the transition either way, so I am not
sure it is the best solution to introduce an extra setting that can
easily go out of sync.

> 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.

It would be a problem, but I do not know if "this is a submodule of
that superproject" link is the only solution, let alone the most
effective one.  It seems to me that you are looking more for
something like GIT_CEILING_DIRECTORIES.