{"thread":{"id":"49127","subject":"git submodule: 3 modules same git repo?","startedAt":"2018-08-14T22:30:18Z","lastAt":"2018-08-15T15:21:29Z","messageCount":11,"participants":["Joakim Tjernlund","Stefan Beller","Junio C Hamano","Jonathan Nieder","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"355633","messageId":"95e4f9df528a40bf3f3e648318904500343abf9a.camel@infinera.com","threadId":"49127","inReplyTo":null,"subject":"git submodule: 3 modules same git repo?","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@infinera.com","sentAt":"2018-08-14T22:27:11Z","receivedAt":"2018-08-14T22:30:18Z","isPatch":false,"sender":{"key":"joakim.tjernlund@infinera.com","avatar":null},"body":"I am trying to create 3 submodules from the same git repo, each pointing to a different branch.\nSince the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3\ntimes, I want one clone and then have the 3 submodules to point to different commits.\n\nIs this possible? If not, could it be added?\n\n Jocke\n"},{"id":"355638","messageId":"20180814223820.123723-1-sbeller@google.com","threadId":"49127","inReplyTo":"95e4f9df528a40bf3f3e648318904500343abf9a.camel@infinera.com","subject":"[PATCH 1/2] store submodule in common dir","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-08-14T22:38:20Z","receivedAt":"2018-08-14T22:38:27Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Signed-off-by: Stefan Beller \n---\n path.c | 1 +\n 1 file changed, 1 insertion(+)\n \nOn Tue, Aug 14, 2018 at 3:27 PM Joakim Tjernlund wrote:\n>\n> I am trying to create 3 submodules from the same git repo, each pointing to a different branch.\n> Since the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3\n> times, I want one clone and then have the 3 submodules to point to different commits.\n>\n> Is this possible? If not, could it be added?\n\nyup.\n\nAccording to recent discussions, it would be just this patch.\n(plus some unspecified amount of work, TBD).\n\nI thought about proposing something proper later, but here is the WIP patch.\n\nThanks,\nStefan \n\ndiff --git a/path.c b/path.c\nindex 34f0f98349a..64c9821b834 100644\n--- a/path.c\n+++ b/path.c\n@@ -115,6 +115,7 @@ static struct common_dir common_list[] = {\n \t{ 1, 1, 1, \"logs/HEAD\" },\n \t{ 0, 1, 1, \"logs/refs/bisect\" },\n \t{ 0, 1, 0, \"lost-found\" },\n+\t{ 0, 1, 0, \"modules\" },\n \t{ 0, 1, 0, \"objects\" },\n \t{ 0, 1, 0, \"refs\" },\n \t{ 0, 1, 1, \"refs/bisect\" },\n-- \n2.18.0.865.gffc8e1a3cd6-goog\n\n"},{"id":"355642","messageId":"xmqqo9e4y2gr.fsf@gitster-ct.c.googlers.com","threadId":"49127","inReplyTo":"20180814223820.123723-1-sbeller@google.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-14T23:04:36Z","receivedAt":"2018-08-14T23:04:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> Signed-off-by: Stefan Beller \n> ---\n> path.c | 1 +\n> 1 file changed, 1 insertion(+)\n> \n> On Tue, Aug 14, 2018 at 3:27 PM Joakim Tjernlund wrote:\n>>\n>> I am trying to create 3 submodules from the same git repo, each pointing to a different branch.\n>> Since the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3\n>> times, I want one clone and then have the 3 submodules to point to different commits.\n>>\n>> Is this possible? If not, could it be added?\n>\n> yup.\n>\n> According to recent discussions, it would be just this patch.\n> (plus some unspecified amount of work, TBD).\n>\n> I thought about proposing something proper later, but here is the WIP patch.\n>\n> Thanks,\n> Stefan \n\nMy understanding of what Joakim wants to do is to have a top-level\nproject that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\nand kernel/v2.6, each of which is a submodule that houses these\nversions of Linux kernel source, but only clone Linus's repository\n(as the up-to-late tree has all the necessary history to check out\nthese past development tracks). And that should be doable with\njust the main checkout, without any additional worktree (it's just\nthe matter of having .git/modules/kernel%2fv2.6/ directory pointed\nby two symlinks from .git/modules/kernel%2fv2.[24], or something\nlike that).\n\nIsn't \"common_dir\" stuff used to decide if each of separate\n\"worktree\" instance (of the superproject) shares \".git/$stuff\"\nwith each other?\n\nUnless I am grossly misinterpreting the original question, I fail to\nsee how changing .git/modules to be shared across worktrees possibly\naffects anything. I am puzzled...\n\n>\n> diff --git a/path.c b/path.c\n> index 34f0f98349a..64c9821b834 100644\n> --- a/path.c\n> +++ b/path.c\n> @@ -115,6 +115,7 @@ static struct common_dir common_list[] = {\n> \t{ 1, 1, 1, \"logs/HEAD\" },\n> \t{ 0, 1, 1, \"logs/refs/bisect\" },\n> \t{ 0, 1, 0, \"lost-found\" },\n> +\t{ 0, 1, 0, \"modules\" },\n> \t{ 0, 1, 0, \"objects\" },\n> \t{ 0, 1, 0, \"refs\" },\n> \t{ 0, 1, 1, \"refs/bisect\" },\n"},{"id":"355643","messageId":"20180814231049.GH142615@aiede.svl.corp.google.com","threadId":"49127","inReplyTo":"95e4f9df528a40bf3f3e648318904500343abf9a.camel@infinera.com","subject":"Re: git submodule: 3 modules same git repo?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-14T23:10:49Z","receivedAt":"2018-08-14T23:10:54Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJoakim Tjernlund wrote:\n\n> I am trying to create 3 submodules from the same git repo, each pointing to a different branch.\n> Since the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3\n> times, I want one clone and then have the 3 submodules to point to different commits.\n>\n> Is this possible? If not, could it be added?\n\nIt's an interesting case. You're not the only one that has wanted\nsomething like this: for example, \"repo\" (a similar tool with some\ndifferences) included the change [1] (repo: Support multiple branches\nfor the same project, 2014-01-30) for this kind of application.\n\nIn practice, it's a bit messy. To allow switching to a branch where\nthe submodule is not present, we store the submodule .git directory\nin the superproject's .git/modules/ directory. This is\nan ordinary .git directory, with files like\n\n\tHEAD\n\tconfig\n\tpacked-refs\n\t[etc]\n\nThe \"git worktree\" tool allows having multiple worktrees for a single\nGit repository. Each worktree has its own HEAD. So the layout would\nlook something like\n\n\t.git/modules//\n\t\tconfig\n\t\tpacked-refs\n\t\t[etc]\n\t\tworktrees/\n\t\t\t/\n\t\t\t\tHEAD\n\t\t\t/\n\t\t\t\tHEAD\n\nBy piggy-backing on the \"git worktree\" feature, this should work\ngreat, but it will take some work to teach Git to set it up.\n\nA side note: as Stefan (cc-ed) mentioned, there is another, related\ninteraction between submodules and \"git worktree\". Namely: I might want\nto have multiple worktrees for a single superproject Git repository.\nIn that case, the layout might look something like\n\n\t.git/\n\t\tHEAD\n\t\tconfig\n\t\tpacked-refs\n\t\t[etc]\n\t\tmodules/\n\t\t\t/\n\t\t\t\tHEAD\n\t\t\t\tconfig\n\t\t\t\tpacked-refs\n\t\t\t\t...\n\t\tworktrees/\n\t\t\t/\n\t\t\t\tHEAD\n\t\t\t/\n\t\t\t\tHEAD\n\nThe patch that Stefan sent heads in this direction, but it has a\nproblem: if the submodule is checked out in both worktrees, then they\ncannot have the same HEAD. So to support that goal well would also\nrequire supporting the goal you've described as a side effect: each\nsubmodule would need to have multiple worktrees, at least one per\nworktree of the superproject.\n\nSorry, that got a bit contorted after a while. If you'd be interested\nin pursuing this, I'd be happy to review any thoughts you have (for\nexample if you write a brief design doc).\n\nMy experience from interacting with the feature [1] is that it is easy\nto make mistakes when trying to support this kind of case. (repo had\nsome bugs due to, for example, multiple checkouts of a repository\ntrying to run \"git prune\" at the same time.) The \"git worktree\"\nfeature should be a good foundation to build on that avoids some of\nthe problems encountered there.\n\nThanks,\nJonathan\n\n[1] https://gerrit-review.googlesource.com/c/git-repo/+/50715/\n"},{"id":"355647","messageId":"xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com","threadId":"49127","inReplyTo":"xmqqo9e4y2gr.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-14T23:20:15Z","receivedAt":"2018-08-14T23:20:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> My understanding of what Joakim wants to do is to have a top-level\n> project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\n> and kernel/v2.6, each of which is a submodule that houses these\n> versions of Linux kernel source, but only clone Linus's repository\n> (as the up-to-late tree has all the necessary history to check out\n> these past development tracks). And that should be doable with\n> just the main checkout, without any additional worktree (it's just\n> the matter of having .git/modules/kernel%2fv2.6/ directory pointed\n> by two symlinks from .git/modules/kernel%2fv2.[24], or something\n> like that).\n\nActually I take the last part of that back. When thought naively\nabout, it may appear that it should be doable, but because each of\nthe modules/* directory in the top-level project has to serve as the\n$GIT_DIR for each submodule checkout, and the desire is to have\nthese three directories to have checkout of three different\nbranches, a single directory under modules/. that is shared among\nthree submodules would *not* work---they must have separate index,\nHEAD, etc.\n\nTheoretically we should be able to make modules/kernel%2fv2.[24]\nadditional \"worktree\"s of modules/kernel%2fv2.6, but given that\nthese are all \"bare\" repositories without an attached working tree,\nI am not sure how that would supposed to work. Thinking about\nhaving multiple worktrees on a single bare repository makes me head\nspin and ache X-<;-)\n"},{"id":"355648","messageId":"CAGZ79kbhwyMTmnwhuaOLOnffaEX_G1L7dR=qvV6Rjncq0POq7g@mail.gmail.com","threadId":"49127","inReplyTo":"xmqqo9e4y2gr.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-08-14T23:23:11Z","receivedAt":"2018-08-14T23:23:24Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 14, 2018 at 4:04 PM Junio C Hamano wrote:\n>\n> Stefan Beller writes:\n>\n> > Signed-off-by: Stefan Beller \n> > ---\n> > path.c | 1 +\n> > 1 file changed, 1 insertion(+)\n> >\n> > On Tue, Aug 14, 2018 at 3:27 PM Joakim Tjernlund wrote:\n> >>\n> >> I am trying to create 3 submodules from the same git repo, each pointing to a different branch.\n> >> Since the repo is somewhat large, I don't want the 3 submodules to clone the same repo 3\n> >> times, I want one clone and then have the 3 submodules to point to different commits.\n> >>\n> >> Is this possible? If not, could it be added?\n> >\n> > yup.\n> >\n> > According to recent discussions, it would be just this patch.\n> > (plus some unspecified amount of work, TBD).\n> >\n> > I thought about proposing something proper later, but here is the WIP patch.\n> >\n> > Thanks,\n> > Stefan\n>\n> My understanding of what Joakim wants to do is to have a top-level\n> project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\n> and kernel/v2.6, each of which is a submodule that houses these\n> versions of Linux kernel source, but only clone Linus's repository\n> (as the up-to-late tree has all the necessary history to check out\n> these past development tracks). And that should be doable with\n> just the main checkout, without any additional worktree (it's just\n> the matter of having .git/modules/kernel%2fv2.6/ directory pointed\n> by two symlinks from .git/modules/kernel%2fv2.[24], or something\n> like that).\n\nAh! I misunderstood due to fast reading.\n\nFor that I think you are interested in the feature added in d92a39590d1\n(Add --reference option to git submodule., 2009-05-04), i.e.\nboth the update and add command take the --reference flag\nthat can be pointed at another repository such as an outside\nclone of these three submodules, so some deduplication will\nbe performed.\n\n> Isn't \"common_dir\" stuff used to decide if each of separate\n> \"worktree\" instance (of the superproject) shares \".git/$stuff\"\n> with each other?\n>\n> Unless I am grossly misinterpreting the original question, I fail to\n> see how changing .git/modules to be shared across worktrees possibly\n> affects anything. I am puzzled...\n\nI did misunderstand grossly.\n\nStefan\n"},{"id":"355649","messageId":"CAGZ79kZtWkbSoMEva5Wv0H1Q23JJ6S3d36LY66+yH2Ot8kADEA@mail.gmail.com","threadId":"49127","inReplyTo":"xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-08-14T23:30:09Z","receivedAt":"2018-08-14T23:30:23Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 14, 2018 at 4:20 PM Junio C Hamano wrote:\n>\n> Junio C Hamano writes:\n>\n> > My understanding of what Joakim wants to do is to have a top-level\n> > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\n> > and kernel/v2.6, each of which is a submodule that houses these\n> > versions of Linux kernel source, but only clone Linus's repository\n> > (as the up-to-late tree has all the necessary history to check out\n> > these past development tracks). And that should be doable with\n> > just the main checkout, without any additional worktree (it's just\n> > the matter of having .git/modules/kernel%2fv2.6/ directory pointed\n> > by two symlinks from .git/modules/kernel%2fv2.[24], or something\n> > like that).\n>\n> Actually I take the last part of that back. When thought naively\n> about, it may appear that it should be doable, but because each of\n> the modules/* directory in the top-level project has to serve as the\n> $GIT_DIR for each submodule checkout, and the desire is to have\n> these three directories to have checkout of three different\n> branches, a single directory under modules/. that is shared among\n> three submodules would *not* work---they must have separate index,\n> HEAD, etc.\n>\n> Theoretically we should be able to make modules/kernel%2fv2.[24]\n> additional \"worktree\"s of modules/kernel%2fv2.6, but given that\n> these are all \"bare\" repositories without an attached working tree,\n> I am not sure how that would supposed to work. Thinking about\n> having multiple worktrees on a single bare repository makes me head\n> spin and ache X-<;-)\n\nWell the worktree feature would do all this in a safe manner, but the existing\nfeature of just cloning the submodules with a reference pointer to another\nrepository at least dedupes some of the object store, although warnings\nneed to be read carefully.\n\nRegarding the worktree, I would think we'd want to have\n\n git worktree --recurse-submodules [list, add, etc]\n\nthat would do a sensible thing for each action on the worktrees,\nbut you seem to propose to have one of the three submodules\nthe main worktree and the other two would be just worktrees of\nthe first.\n\n I guess you could just\n\n* init/update one of the submodules\n* add their worktrees manually pointed to where\n the 2nd and 3rd submodule would go.\n* make a symbolic link from\n ln -s .git/modules/<1st>/worktrees/<2nd> .git/modules/<2nd>\n ln -s .git/modules/<1st>/worktrees/<3rd> .git/modules/<3rd>\n\nas then submodule operations should \"just work\" and by having the\nworktrees in-place where the submodules are, we'd also have\nall the protection against overzealous garbage collection, too.\n\nStefan\n"},{"id":"355659","messageId":"20180815004705.GA5932@aiede.svl.corp.google.com","threadId":"49127","inReplyTo":"xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-15T00:47:05Z","receivedAt":"2018-08-15T00:47:09Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Theoretically we should be able to make modules/kernel%2fv2.[24]\n> additional \"worktree\"s of modules/kernel%2fv2.6, but given that\n> these are all \"bare\" repositories without an attached working tree,\n> I am not sure how that would supposed to work. Thinking about\n> having multiple worktrees on a single bare repository makes me head\n> spin and ache X-<;-)\n\nAgreed about spinning head. This is why I suggested at [1] that\nanyone intereseted in this start with description of their proposed\ndesign, which would have three benefits:\n\n- after implementation, it would document the intent behind whatever\n we choose to do, hopefully saving people debugging or improving this\n code some head spinning\n\n- it would allow subject matter experts on-list to suggest refinements\n and simplifications\n\n- it would avoid the interested contributor going too far down a blind\n alley in case their initial proposal has a fatal flaw\n\nI also agree with the \"theoretically we should be able to make it\nwork\". As described in [1], I think most of this is work we're going\nto have to do eventually, as part of properly supporting multiple\nworktrees for a superproject. But I don't want to set wrong\nexpectations: this will be hard.\n\nThanks,\nJonathan\n\n[1] https://public-inbox.org/git/20180814231049.GH142615@aiede.svl.corp.google.com/\n"},{"id":"355678","messageId":"676a61f0e87742fe591eb91fcf3509b75645e030.camel@infinera.com","threadId":"49127","inReplyTo":"xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@infinera.com","sentAt":"2018-08-15T08:28:42Z","receivedAt":"2018-08-15T08:30:27Z","isPatch":true,"sender":{"key":"joakim.tjernlund@infinera.com","avatar":null},"body":"On Tue, 2018-08-14 at 16:20 -0700, Junio C Hamano wrote:\n> 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.\n> \n> \n> Junio C Hamano writes:\n> \n> > My understanding of what Joakim wants to do is to have a top-level\n> > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\n> > and kernel/v2.6, each of which is a submodule that houses these\n> > versions of Linux kernel source, but only clone Linus's repository\n> > (as the up-to-late tree has all the necessary history to check out\n> > these past development tracks). And that should be doable with\n> > just the main checkout, without any additional worktree (it's just\n> > the matter of having .git/modules/kernel%2fv2.6/ directory pointed\n> > by two symlinks from .git/modules/kernel%2fv2.[24], or something\n> > like that).\n> \n> Actually I take the last part of that back. When thought naively\n> about, it may appear that it should be doable, but because each of\n> the modules/* directory in the top-level project has to serve as the\n> $GIT_DIR for each submodule checkout, and the desire is to have\n> these three directories to have checkout of three different\n> branches, a single directory under modules/. that is shared among\n> three submodules would *not* work---they must have separate index,\n> HEAD, etc.\n> \n> Theoretically we should be able to make modules/kernel%2fv2.[24]\n> additional \"worktree\"s of modules/kernel%2fv2.6, but given that\n> these are all \"bare\" repositories without an attached working tree,\n> I am not sure how that would supposed to work. Thinking about\n> having multiple worktrees on a single bare repository makes me head\n> spin and ache X-<;-)\n\nYou nailed it ! :)\nMy head spins just reading this so I think I got my answer. I can be done\nbut will be tricky to impl. \nI will keep an eye on how submodules develops, sure would be a welcome feature.\n\n Jocke\n"},{"id":"355679","messageId":"3bd471a5a970adf18cf279c4db217e352eea2506.camel@infinera.com","threadId":"49127","inReplyTo":"676a61f0e87742fe591eb91fcf3509b75645e030.camel@infinera.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@infinera.com","sentAt":"2018-08-15T08:39:05Z","receivedAt":"2018-08-15T08:41:48Z","isPatch":true,"sender":{"key":"joakim.tjernlund@infinera.com","avatar":null},"body":"On Wed, 2018-08-15 at 10:28 +0200, Joakim Tjernlund wrote:\n> On Tue, 2018-08-14 at 16:20 -0700, Junio C Hamano wrote:\n> > 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.\n> > \n> > \n> > Junio C Hamano writes:\n> > \n> > > My understanding of what Joakim wants to do is to have a top-level\n> > > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4\n> > > and kernel/v2.6, each of which is a submodule that houses these\n> > > versions of Linux kernel source, but only clone Linus's repository\n> > > (as the up-to-late tree has all the necessary history to check out\n> > > these past development tracks). And that should be doable with\n> > > just the main checkout, without any additional worktree (it's just\n> > > the matter of having .git/modules/kernel%2fv2.6/ directory pointed\n> > > by two symlinks from .git/modules/kernel%2fv2.[24], or something\n> > > like that).\n> > \n> > Actually I take the last part of that back. When thought naively\n> > about, it may appear that it should be doable, but because each of\n> > the modules/* directory in the top-level project has to serve as the\n> > $GIT_DIR for each submodule checkout, and the desire is to have\n> > these three directories to have checkout of three different\n> > branches, a single directory under modules/. that is shared among\n> > three submodules would *not* work---they must have separate index,\n> > HEAD, etc.\n> > \n> > Theoretically we should be able to make modules/kernel%2fv2.[24]\n> > additional \"worktree\"s of modules/kernel%2fv2.6, but given that\n> > these are all \"bare\" repositories without an attached working tree,\n> > I am not sure how that would supposed to work. Thinking about\n> > having multiple worktrees on a single bare repository makes me head\n> > spin and ache X-<;-)\n> \n> You nailed it ! :)\n> My head spins just reading this so I think I got my answer. I can be done\n> but will be tricky to impl. \n> I will keep an eye on how submodules develops, sure would be a welcome feature.\n> \n> Jocke\n\nOn a related note, it would be great if git could support sparse checkout/clone\nfor submodules, now one have to manually add .git/info/sparse-checkout.\nIf sparse clone and sparse checkout could be saved in the submodule, then there\nwould be no problem with 3 copies of the same repo in my submodules.\n\n Jocke\n"},{"id":"355690","messageId":"CACsJy8DH+c0tHS9VpirdE97G3+roWhvXfb-jcjW7n-5nuZo3=A@mail.gmail.com","threadId":"49127","inReplyTo":"xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/2] store submodule in common dir","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-08-15T15:20:59Z","receivedAt":"2018-08-15T15:21:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Aug 15, 2018 at 1:20 AM Junio C Hamano wrote:\n> Theoretically we should be able to make modules/kernel%2fv2.[24]\n> additional \"worktree\"s of modules/kernel%2fv2.6, but given that\n> these are all \"bare\" repositories without an attached working tree,\n> I am not sure how that would supposed to work. Thinking about\n> having multiple worktrees on a single bare repository makes me head\n> spin and ache X-<;-)\n\nI could only read the mail subject this morning and thought a bit\nabout it on the train, and came to the same conclusion that \"git\nworktree\" is the way to go.\n\nThe bareness should not affect this at all. If you meant core.bare,\nit can only affect the main repo. But what I'm thinking is repos with\nonly linked worktrees and no main one. So when you \"submodule update\"\na repo, you \"clone -n\", then \"git worktree add\" to put a worktree in\nplace. The repo is strictly speaking not bare, it just does not have a\nmain worktree.\n\nThe main HEAD should be detached so that it does not block any\nworktree from checking out branches. If we could get away without the\nmain HEAD, that would be great, but HEAD is part of the repo signature\nso it has to stay (and we may end up keeping more objects for this\nHEAD even after every other heads don't need the same objects\nanymore).\n\nThis also solves the problem with mupltiple worktrees on a repo with\nsubmodules, where we have the same problems (if I add a new worktree\nof the superproject, where do the new submodules go?). In this case\nideally all worktrees should have separate ref namespaces to maintain\nthe \"separate repo\" view that we currently have, but I guess we can\nlive with sharing refs for a while.\n\nAnd simply sharing $GIT_DIR/modules won't work. For starter, it breaks\nexisting setups. What I've wanted to do is adding a shared \"common\"\ndirectory. Then you could have \"common/modules\" (among other future\ncommon stuff), which is shared across all worktrees, but you don't\nhave to add extra share rules since it's already covered by the\n\"common\" rule.\n-- \nDuy\n"}]}