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

Jonathan Nieder [off-list ref] 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.