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

From: Jonathan Nieder <jrnieder@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Emily Shaffer <emilyshaffer@google.com>,
	git@vger.kernel.org, Albert Cui <albertcui@google.com>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	Matheus Tavares Bernardino <matheus.bernardino@usp.br>,
	Jacob Keller <jacob.keller@gmail.com>,
	Atharva Raykar <raykar.ath@gmail.com>,
	Derrick Stolee <stolee@gmail.com>,
	Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH v6 0/5] teach submodules to know they're submodules
Date: Mon, 7 Feb 2022 11:56:07 -0800	[thread overview]
Message-ID: <YgF5V2Y0Btr8B4cd@google.com> (raw)
In-Reply-To: <220204.86pmo34d2m.gmgdl@evledraar.gmail.com>

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@gmail.com/