{"thread":{"id":"29592","subject":"nested git repos (not submodules)","startedAt":"2012-02-10T02:34:42Z","lastAt":"2012-02-10T22:30:57Z","messageCount":5,"participants":["Neal Kreitzinger","Andrew Ardill","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184316","messageId":"jh1vo3$7af$1@dough.gmane.org","threadId":"29592","inReplyTo":null,"subject":"nested git repos (not submodules)","fromName":"Neal Kreitzinger","fromEmail":"neal@rsss.com","sentAt":"2012-02-10T02:34:42Z","receivedAt":"2012-02-10T02:34:42Z","isPatch":false,"sender":{"key":"neal@rsss.com","avatar":null},"body":"In the worktree of a particular git repo, the user has made a subdir \n(worktree/subdir) of the worktree (worktree/.git) its own repo \n(worktree/subdir/.git).  Is there a danger of worktree/.git and \nworktree/subdir/.git crossing wires?  Are literally nested git repos (whose \nworktrees are in turn tracked as subdirs by upper-level git repo(s)) a \nsupported/valid model in regards to git.git (NOT git-addons)?\n\nSymptomatically, I have observed the following so far:\n(1) worktree/.git is \"ignoring\" (or unaware of) worktree/subdir/.git because \nit is treating subdir/ as if subdir/.git wasn't there and is not listing \nsubdir/.git as untracked.  I'm not sure if this is an unintended side-effect \nof git ignoring .git(s) automatically, or if having subdir/.git's (w/out \nhaving them defined as submodules) is an expected \n(reasonable/sane/recommended) model for git.git users.\n(2) running git commands with pwd=worktree/subdir/ acts upon \nworktree/subdir/.git (subdir/ is regarded as the toplevel of subdir/.git as \nopposed to a subdir of worktree/.git) and is seemingly oblivious to \nworktree.git.\n\nI suspect submodules is the \"correct\" way to implement the effect of nested \ngit repos.  That being said, this literal nested git repo is a temporary \nband-aid and I don't expect it to be propogated, but I do have to deal \n(react) with it in the meantime.  I'm thinking I can manage that and deal \nwith annoyances as they arise, unless there are any unseen landmines I'm not \naware of.  Please advise.\n\n(I also wouldn't be surprised to hear that this is exactly how submodules \nreally first started in theory or practice.)\n\nThanks in advance for any feedback.\n\nv/r,\nneal \n"},{"id":"184318","messageId":"CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com","threadId":"29592","inReplyTo":"jh1vo3$7af$1@dough.gmane.org","subject":"Re: nested git repos (not submodules)","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-02-10T03:47:39Z","receivedAt":"2012-02-10T03:47:39Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"> Thanks in advance for any feedback.\n\nMy understanding was that such a configuration is essentially tracking\nthe same set of files in two different git repositories. The location\nof the .git is not important, I could just as easily set the working\ndirectory of any git repository to be a folder tracked by another\nrepository.\n\nMy concerns would be based primarily on the different repositories\ntrying to act on the same files at the same time. Ignoring the\nsub-folder completely within the encompassing repository would avoid\nthat, however you might have use cases that prohibit that.\n\nOut of interest, what itch are you scratching by using this model?\n\nRegards,\n\nAndrew Ardill\n"},{"id":"184322","messageId":"7vd39ns4py.fsf@alter.siamese.dyndns.org","threadId":"29592","inReplyTo":"jh1vo3$7af$1@dough.gmane.org","subject":"Re: nested git repos (not submodules)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T04:16:25Z","receivedAt":"2012-02-10T04:16:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Neal Kreitzinger\" <neal@rsss.com> writes:\n\n> In the worktree of a particular git repo, the user has made a subdir \n> (worktree/subdir) of the worktree (worktree/.git) its own repo \n> (worktree/subdir/.git).  Is there a danger of worktree/.git and \n> worktree/subdir/.git crossing wires?  \n\nThe repository controlled by worktree/.git should behave as if subdir/\ndoes not exist, except that obviously the project cannot have a regular\nfile \"subdir\" in it.  When you chdir to worktree/subdir, everything in\nthere should behave as if worktree/.git directory does not exist.\n\nAt least that is the design, and it indeed is how I arrange my primary\nworking tree (I have two \"clones\" at /git/git.git/ and /git/git.git/Meta,\nand the latter has a checkout of the \"todo\" branch), so I would make\nnoises about any breakage for such a layout.\n\nI do not know offhand if an attempt to add files inside subdir to the\nrepository controlled by worktree/.git is always correctly prohibited by\nthe code, though, as our code often forgets to error out \"stupid user\nmistakes\", and running \"git add subdir/bar\" when in worktree/ falls into\nthat category.\n\nAnd the use of that layout predates the submodules by a large margin.\nIn fact, when people suggest use of submodules when the toplevel and the\nsublevel do not even need tight version dependencies, some of their use\ncases might be better supported by using the simply-nested layout without\neven letting the toplevel be aware of the sublevel.\n"},{"id":"184410","messageId":"4F359528.1060603@gmail.com","threadId":"29592","inReplyTo":"CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com","subject":"Re: nested git repos (not submodules)","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-02-10T22:07:36Z","receivedAt":"2012-02-10T22:07:36Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 2/9/2012 9:47 PM, Andrew Ardill wrote:\n\n> My understanding was that such a configuration is essentially\n> tracking the same set of files in two different git repositories. The\n> location of the .git is not important, I could just as easily set the\n> working directory of any git repository to be a folder tracked by\n> another repository.\n>\n> My concerns would be based primarily on the different repositories\n> trying to act on the same files at the same time. Ignoring the\n> sub-folder completely within the encompassing repository would avoid\n> that, however you might have use cases that prohibit that.\n>\nWORKTREE/SUBDIR/ was already tracked by WORKTREE/.git because the files \nin WORKTREE/SUBDIR/ directly correlate to WORKTREE/ files (ie., \nWORKTREE/., WORKTREE/SUBDIR2/., WORKTREE/SUBDIR3/.).  This is the \npublished model.\n\n> Out of interest, what itch are you scratching by using this model?\n>\n(I can only speculate) I think it was intended to ensure that he would \nonly be modifying the WORKTREE/SUBDIR/ files of WORKTREE/.git.  He did \nsome sequence of commands with the end result of:\n\n(a) bare repo HISPATH/SUBDIR.git\n\nand\n\n(b1)\nWORKTREE/.git\nWORKTREE/SUBDIR/\n\nis now\n\n(b2)\nWORKTREE/.git\nWORKTREE/SUBDIR/.git\n\nwhich means that the files of WORKTREE/SUBDIR are now tracked by \nWORKTREE/.git and WORKTREE/SUBDIR/.git, as you stated.\n\nDue to a drop-dead short-term deadline, I am being compelled to \"just \ndeal with it\" (work around the annoyances) unless there is a dire reason \nit will blow up in our faces.  At this point, (b2) is more-or-less an \nintermediate \"integration repo\" between (a) and (b1-canonical), and I'm \nassuming I can just jump thru some hoops to accomplish the integration \nwhen the time comes (unless I hear of or step on any landmines).\n\nNow that the newsgroup has confirmed that having \"a repo that tracks the \nworktree of a nested repo\" is not a sound model, I can advise against it \non a go-forward basis without being concerned that I'm not open to new \nideas.\n\n\nv/r,\nneal\n"},{"id":"184413","messageId":"4F359AA1.2000901@gmail.com","threadId":"29592","inReplyTo":"7vd39ns4py.fsf@alter.siamese.dyndns.org","subject":"Re: nested git repos (not submodules)","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-02-10T22:30:57Z","receivedAt":"2012-02-10T22:30:57Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 2/9/2012 10:16 PM, Junio C Hamano wrote:\n>\n> The repository controlled by worktree/.git should behave as if subdir/\n> does not exist, except that obviously the project cannot have a regular\n> file \"subdir\" in it.  When you chdir to worktree/subdir, everything in\n> there should behave as if worktree/.git directory does not exist.\n>\n> At least that is the design, and it indeed is how I arrange my primary\n> working tree (I have two \"clones\" at /git/git.git/ and /git/git.git/Meta,\n> and the latter has a checkout of the \"todo\" branch), so I would make\n> noises about any breakage for such a layout.\n>\nI now see that most of the concept of \"a repo worktree path with an o/s \nsubdir containing another repo\" is valid provided that the repo is \nignoring the worktree of the subdir repo.\n\n> I do not know offhand if an attempt to add files inside subdir to the\n> repository controlled by worktree/.git is always correctly prohibited by\n> the code, though, as our code often forgets to error out \"stupid user\n> mistakes\", and running \"git add subdir/bar\" when in worktree/ falls into\n> that category.\n>\nIn my situation, WORKTREE/.git is tracking the worktree of \nWORKTREE/SUBDIR/.git.  Before WORKTREE/SUBDIR/.git was created, \nWORKTREE/SUBDIR/ was already being tracked by WORKTREE/.git because \nWORKTREE/SUBDIR/. directly correlates to the rest of WORKTREE/., \nWORKTREE/SUBDIR2/., etc.  Now that I know that having \"a repo tracking \nthe worktree of a nested repo\" is not a sound model, I can advise \nagainst it on a go-forward basis without being concerned that I am not \nopen to new ideas.\n\n> And the use of that layout predates the submodules by a large margin.\n> In fact, when people suggest use of submodules when the toplevel and the\n> sublevel do not even need tight version dependencies, some of their use\n> cases might be better supported by using the simply-nested layout without\n> even letting the toplevel be aware of the sublevel.\n\nI will keep this in mind when adding submodules.\n\nThanks!\n\nv/r,\nneal\n"}]}