Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

Stefan Beller <sbeller@google.com> writes:

This is no different from what you later call "embedded". The only difference is that embedded thing hasn't seen its initial commit.

i.e. what "submodule init" gives you.

i.e. what "submodule update" after "submodule init" gives you.

Is this any different from "existing" case for the purpose of discussing the interaction between a submodule (and its checkout) and having possibly multiple worktrees of its superproject?

I agree that when a top-level superproject has multiple worktrees these multiple worktrees may want to have the same submodule in different states, but I'd imagine that they want to share the same physical repository (i.e. $GIT_DIR/modules/$name of the primary worktree of the superproject)---is everybody involved in the discussion share this assumption?

Assuming that everybody is on the same page, that means "do we have the repository for that submodule, and if so where in our local filesystem?" is a bit of information shared across the worktrees of the superproject. And the "name" used to identify the submodule is also shared across these worktrees of the superproject, as it is meant to be a unique (within the superproject) identifier for that "other" project it uses, no matter where in the superproject's working tree (note: this is "working tree", not "worktree") it would be checked out, and where the upstream URL to get further updates to the submodule is (i.e. that URL may change over time if they relocate, or it may even change when the user who works on the superproject decides to use a different mirror).

What can be different between the instantiation of the same submodule in these multiple worktrees, and how they should be recorded?

 * submodule.$name.URL?  I am not sure if we want to have different
   "upstreams" depending on the worktree of the superproject.  While
   there is no fundamental reason to forbid it, having to maintain a
   single local repository for a submodule would mean they would
   need to be treated as separate "remotes" in the submodule
   repository.

 * submodule.$name.path of course can be different depending on
   which commit of the superproject is checked out in the worktree,
   as the superproject may move the submodule binding site across
   its versions.

 * submodule.$name.update, submodule.$name.ignore,
   submodule.$name.branch, etc. would need to be all different among
   worktrees of the superproject, as that is the whole point of
   being able to work on separate branches of the superproject in
   separate worktrees.

Somewhere in this discussion thread, you present the conclusion of your discussion with Jonathan Nieder that there needs a separate "should the submodule directory be populated?" bit, which currently is tied to submodule.$name.URL in $GIT_DIR/config. I tend to agree that knowing where you get other people's update of that submodule repository should come from and wanting to have/keep a checkout of that submodule in the working tree of a particular worktree are two different things, so such a separate bit would be needed, and that would belong to per-worktree configuration.