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

From: Emily Shaffer <emilyshaffer@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Albert Cui" <albertcui@google.com>,
	"Phillip Wood" <phillip.wood123@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"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: Thu, 10 Feb 2022 14:12:16 -0800	[thread overview]
Message-ID: <YgWNwIE4ZLSWAr6n@google.com> (raw)
In-Reply-To: <xmqqy22lcj2m.fsf@gitster.g>

On Tue, Feb 08, 2022 at 10:24:49AM -0800, Junio C Hamano wrote:
> 
> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
> > My point with this example is that it's useful to have a definition of
> > what is a submodule repository, to make it unambiguous whether this
> > repository is a submodule or whether it's just a repository that
> > happens to have been cloned inside of a git-managed worktree.
> 
> OK, together with the other "no need to let NFS automounter worry
> about parent directories", it makes a very successful argument for a
> single bit (i.e. this is a free-standing repository and is not a
> submodule, so no need to auto-discover if it is one).  I think the
> "Alternatively" you later mention to solve ambiguity with just a
> single bit, without "this is a submodule of that superproject"
> linkage, is essentially the same?

That resolution - "teach submodules to know they're submodules, but not
whose submodule they are" - would still count as a success to me. The
reason I proposed a path instead of a boolean here was simply because
storing a path is a boolean (by whether it's present or not) *and*
additional information (the path to the superproject), and it seemed
silly to me to opt for less information. Or, to put it another way - "am
I a submodule?" seems pretty vital, and "yes, and I belong to xyz" is an
optimization on top of that. So I don't terribly mind sending this as
just a boolean, if we feel that the effort to keep it up outweighs the
benefit of saving us a filesystem walk.

I'm not completely convinced that it does, though - would the addition
of a 'git fsck' check for this config be satisfactory? In other words,
is the problem that the execution of this series wasn't thorough enough
and it should be refined, or that the concept itself is beyond saving?

 - Emily

> 
> But I do not think it argues for the need to say "a config, not
> filesystem layout, must be the single source of truth to say which
> superproject this repository belongs as its submodule".
> 
> > This would be the first time in git history that we are saying a
> > property of a repository depends on having to examine files outside of
> > it.
> 
> Well, path-based configuration inclusion, with configuration driven
> hooks, I do not think the distinction matters much anymore in these
> days.
> 
> > I guess the main question I'd have is, why _wouldn't_ I want a
> > submodule to be able to point to the superproject containing it?
> 
> Because with (the absense of) a single "this is freestanding" bit, 
> by default the filesystem layout can already "point" at it?