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

From: Derrick Stolee <stolee@gmail.com>
Date: Nov 9, 2021, 15:58 UTC
Message-ID: <82efc900-8518-3bb3-2524-8997475f1a45@gmail.com>
In-Reply-To: <YYmuqEQUaB1a8Gs1@google.com>

On 11/8/2021 6:11 PM, Emily Shaffer wrote:

Show 11 quoted lines

> Yeah, I think we may be overthinking it, especially with the concerns
> about common dir vs. gitdir. More specifically - I think we accidentally
> did the right thing in the previous iteration by using the gitdir :)
> 
> I think we can probably put it pretty simply:
> submodule.superprojectGitDir should point from the most local gitdir of
> the submodule to the most local gitdir of the superproject.
> 
> Luckily there are not so many permutations to worry about here.
> 
> Super doesn't have worktrees, sub doesn't have worktrees:

> Super doesn't have worktrees, sub does have worktrees (and as you
> suggest above, right now this would have to be created carefully and
> manually, but later we probably want this to Just Work):

> Super has worktrees, sub doesn't have worktrees:
> Actually, I think in the future this might not be possible, if we want
> to make `git worktree add --recurse-submodules` work gracefully (and I
> do want that). But in the interim, in practice it looks like this:

> Both super and sub have worktrees:
> And this won't exist until we have graceful support of `git worktree add
> --recurse-submodules` or with some manual effort, now.

Show 28 quoted lines

> I think this will give us access to both the worktree gitdir *and* the
> common gitdir:
> 
>   ~/git/.git/worktrees/git-second [GIT_DIR!]$ git rev-parse --git-common-dir
>   /usr/local/google/home/emilyshaffer/git/.git
> 
> So that means from any submodule, we can determine:
>  - submodule's gitdir (from the .git link in the submodule wt)
>  - submodule's common dir (from existing commands)
>  - gitdir of superproject which submodule inhabits (from the config in
>    the submodule's gitdir, or the submodule's config.worktree)
>  - common dir of superproject (from existing commands + prior config)
> 
> The upshot to me, then, means that we should be 1) making sure to get
> the path to the gitdir, not the common dir, of the superproject; and 2)
> using helpers to write to the worktree config, not to the local config,
> of the submodule. In other words, we want to avoid the following:
> 
> .git/
>   modules/
>     sub/
>       worktrees/
>         wt/
> 	  config
>       config <- "submodule.superprojectGitDir = ../../../.." as written by the worktree
> 
> Will take a look at the rest of the comments too, but this sounds like a
> reasonable approach to me.

I agree, that this seems reasonable. Spelling it out carefully like this, along with your list of possibilities, clarifies where the data is located and how we can construct any information we need from that.

You point out that there are cases that can be a bit tricky to get into with current features, but this config approach won't make that any worse right now.

Thanks, -Stolee