Hi, Joakim Tjernlund wrote: > I am trying to create 3 submodules from the same git repo, each pointing to a different branch. > Since the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3 > times, I want one clone and then have the 3 submodules to point to different commits. > > Is this possible? If not, could it be added? It's an interesting case. You're not the only one that has wanted something like this: for example, "repo" (a similar tool with some differences) included the change [1] (repo: Support multiple branches for the same project, 2014-01-30) for this kind of application. In practice, it's a bit messy. To allow switching to a branch where the submodule is not present, we store the submodule .git directory in the superproject's .git/modules/<submodule name> directory. This is an ordinary .git directory, with files like HEAD config packed-refs [etc] The "git worktree" tool allows having multiple worktrees for a single Git repository. Each worktree has its own HEAD. So the layout would look something like .git/modules/<submodule name>/ config packed-refs [etc] worktrees/ <branch1>/ HEAD <branch2>/ HEAD By piggy-backing on the "git worktree" feature, this should work great, but it will take some work to teach Git to set it up. A side note: as Stefan (cc-ed) mentioned, there is another, related interaction between submodules and "git worktree". Namely: I might want to have multiple worktrees for a single superproject Git repository. In that case, the layout might look something like .git/ HEAD config packed-refs [etc] modules/ <submodule name>/ HEAD config packed-refs ... worktrees/ <branch1>/ HEAD <branch2>/ HEAD The patch that Stefan sent heads in this direction, but it has a problem: if the submodule is checked out in both worktrees, then they cannot have the same HEAD. So to support that goal well would also require supporting the goal you've described as a side effect: each submodule would need to have multiple worktrees, at least one per worktree of the superproject. Sorry, that got a bit contorted after a while. If you'd be interested in pursuing this, I'd be happy to review any thoughts you have (for example if you write a brief design doc). My experience from interacting with the feature [1] is that it is easy to make mistakes when trying to support this kind of case. (repo had some bugs due to, for example, multiple checkouts of a repository trying to run "git prune" at the same time.) The "git worktree" feature should be a good foundation to build on that avoids some of the problems encountered there. Thanks, Jonathan [1] https://gerrit-review.googlesource.com/c/git-repo/+/50715/
