On Wed, Aug 15, 2018 at 1:20 AM Junio C Hamano <gits...@pobox.com> wrote: > Theoretically we should be able to make modules/kernel%2fv2.[24] > additional "worktree"s of modules/kernel%2fv2.6, but given that > these are all "bare" repositories without an attached working tree, > I am not sure how that would supposed to work. Thinking about > having multiple worktrees on a single bare repository makes me head > spin and ache X-<;-)
I could only read the mail subject this morning and thought a bit about it on the train, and came to the same conclusion that "git worktree" is the way to go. The bareness should not affect this at all. If you meant core.bare, it can only affect the main repo. But what I'm thinking is repos with only linked worktrees and no main one. So when you "submodule update" a repo, you "clone -n", then "git worktree add" to put a worktree in place. The repo is strictly speaking not bare, it just does not have a main worktree. The main HEAD should be detached so that it does not block any worktree from checking out branches. If we could get away without the main HEAD, that would be great, but HEAD is part of the repo signature so it has to stay (and we may end up keeping more objects for this HEAD even after every other heads don't need the same objects anymore). This also solves the problem with mupltiple worktrees on a repo with submodules, where we have the same problems (if I add a new worktree of the superproject, where do the new submodules go?). In this case ideally all worktrees should have separate ref namespaces to maintain the "separate repo" view that we currently have, but I guess we can live with sharing refs for a while. And simply sharing $GIT_DIR/modules won't work. For starter, it breaks existing setups. What I've wanted to do is adding a shared "common" directory. Then you could have "common/modules" (among other future common stuff), which is shared across all worktrees, but you don't have to add extra share rules since it's already covered by the "common" rule. -- Duy
