On Tue, 2018-08-14 at 16:20 -0700, Junio C Hamano wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > My understanding of what Joakim wants to do is to have a top-level > > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4 > > and kernel/v2.6, each of which is a submodule that houses these > > versions of Linux kernel source, but only clone Linus's repository > > (as the up-to-late tree has all the necessary history to check out > > these past development tracks). And that should be doable with > > just the main checkout, without any additional worktree (it's just > > the matter of having .git/modules/kernel%2fv2.6/ directory pointed > > by two symlinks from .git/modules/kernel%2fv2.[24], or something > > like that). > > Actually I take the last part of that back. When thought naively > about, it may appear that it should be doable, but because each of > the modules/* directory in the top-level project has to serve as the > $GIT_DIR for each submodule checkout, and the desire is to have > these three directories to have checkout of three different > branches, a single directory under modules/. that is shared among > three submodules would *not* work---they must have separate index, > HEAD, etc. > > 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-<;-) You nailed it ! :) My head spins just reading this so I think I got my answer. I can be done but will be tricky to impl. I will keep an eye on how submodules develops, sure would be a welcome feature. Jocke
