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

[Jonathan Nieder <jrnieder@gmail.com>]

Emily Shaffer wrote:
> 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.

Thanks, both.  Sounds like a good path forward.

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