On Wed, 2018-08-15 at 10:28 +0200, Joakim Tjernlund wrote: > 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 On a related note, it would be great if git could support sparse checkout/clone for submodules, now one have to manually add .git/info/sparse-checkout. If sparse clone and sparse checkout could be saved in the submodule, then there would be no problem with 3 copies of the same repo in my submodules. Jocke
