Re: [PATCH v5 0/4] cache parent project's gitdir in submodules

[Derrick Stolee <stolee@gmail.com>]

On 11/4/2021 7:49 PM, Emily Shaffer wrote:

> The only real change here is a slight semantics change to map from
> <submodule gitdir> to <superproject common git dir>. In every case
> *except* for when the superproject has a worktree, this changes nothing.
> For the case when the superproject has a worktree, this means that now
> submodules will refer to the general superproject common dir (e.g. no
> worktree-specific refs or configs or whatnot).
> 
> I *think* that because a submodule should exist in the context of the
> common dir, not the worktree gitdir, that is ok. However, it does mean
> it would be difficult to do something like sharing a config specific to
> the worktree (the initial goal of this series).
> 
> $ROOT/.git
> $ROOT/.git/config.superproject <- shared by $ROOT/.git/modules/sub
> $ROOT/.git/modules/sub <- points to $ROOT/.git
> $ROOT/.git/worktrees/wt
> $ROOT/.git/worktrees/wt/config.superproject <- contains a certain config-based pre-commit hook
> 
> If the submodule only knows about the common dir, that is tough, because
> the submodule would basically have to guess which worktree it's in from
> its own path. There would be no way for '$WT/sub' to inherit
> '$ROOT/.git/worktrees/wt/config.superproject'.
> 
> That said... right now, we don't support submodules in worktrees very
> well at all. A submodule in a worktree will get a brand new gitdir in
> $ROOT/.git/worktrees/modules/ (and that brand new gitdir would point to
> the super's common dir). So I think we can punt on this entire question
> until we teach submodules and worktrees to play more gracefully together
> (it's on my long list...),

(I omit a portion that will be discussed later.)

> Or, to summarize the long ramble above: "this is still kind of weird
> with worktrees, but let's fix it later when we fix worktrees more
> thoroughly".

I'm concerned about punting here, because making a messy situation worse
is unlikely to have a clean way out. Could we set up a design that works
with superproject worktrees?

You mentioned that submodules cannot have worktrees. At least, you said
that 'absorbgitdirs' does not allow them. Could those subprojects still
exist and be registered as submodules without using that command?

What I'm trying to hint at is that if the submodules can't have
worktrees, then maybe we could make their 'config.worktree' files be
relative to the superproject worktrees. Then, these submodules could
point to the commondir in their base config and _also_ to the worktree
gitdir in their config.worktree.

The issue that is immediately obvious here is that my definition is
circular: we need to know the superproject worktree in order to discover
the config.worktree which contains the information about the superproject
worktree.

> and at that time we can probably introduce a
> pointer from $ROOT/.git/modules/sub/worktrees/wt/ to
> $ROOT/.git/worktrees/wt/....

Your idea here appears to assume that if the superproject has worktrees,
then the submodule is divided into worktrees in an exact correspondence.
This would allow the submodule's config.worktree to point to the
superproject's worktree (or possibly it could be inferred from the
submodule's worktree relative to the submodule's commondir).

This seems like an interesting way forward, but requires changing how
'git absorbgitdirs' works, along with changes to 'git worktree' or other
submodule commands when the submodule first appears during a 'git checkout'
in a worktree. I imagine there are a lot of "gotchas" here. It is worth
spending some time imagining how to create this setup and/or enforce it
as submodules are added in the lifecycle of a repository, if only to
validate the config design presented by this series.

Thanks,
-Stolee