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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 10, 2022, 22:53 UTC
Message-ID: <YgWXVybMBIyKSvN9@google.com>
In-Reply-To: <YgWNwIE4ZLSWAr6n@google.com>

Emily Shaffer wrote:

> On Tue, Feb 08, 2022 at 10:24:49AM -0800, Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 15 quoted lines

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

Thanks, both.  Sounds like a good path forward.

[...]

Show 5 quoted lines

>                              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

Personally, I'm convinced --- e.g., life gets painful enough when core.worktree ends up pointing to the wrong path, so being able to avoid that complexity seems like a nice outcome.

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

For the absorbed case, the path to the superproject should be pretty stable, and in that case it's probably possible to make this robust enough. (That said, the path to the superproject gitdir would typically just be "../..", at least as long as we have the other patch to escape slashes in the submodule name.) In the non-absorbed case, it seems likely to get messy fast because a user can "mv" the submodule around.

Another kind of case that gets interesting is when there are multiple superproject worktrees and multiple submodule worktrees. Does the relative path become a per-worktree variable? Using a boolean saves us from having to think through it.

Thanks for the clear explanations, Jonathan