Stefan Beller <sbeller@xxxxxxxxxx> writes: > From a users POV there are: > * non existent submodules (no gitlink recorded, no config set, > no repo in place) > * not initialized submodules (gitlink is recorded, no config set, > and an empty repo is put in the working tree as a place holder). This is no different from what you later call "embedded". The only difference is that embedded thing hasn't seen its initial commit. > * initialized submodules (gitlink is recorded, the config > submodule .<name>.url is copied from the .gitmodules file to .git/config. > an empty dir in the working tree as a place holder) > A user may change the configuration before the next step as the url in > the .gitmodules file may be wrong and the user doesn't want to > rewrite history i.e. what "submodule init" gives you. > * existing submodules (gitlink is recorded, the config option is set > and instead of an empty placeholder dir, we actually have a git > repo there.) i.e. what "submodule update" after "submodule init" gives you. > * matching submodules (the recorded git link matches > the actual checked out state of the repo!, config option and repo exist) 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html