nested git repos (not submodules)

In the worktree of a particular git repo, the user has made a subdir (worktree/subdir) of the worktree (worktree/.git) its own repo (worktree/subdir/.git). Is there a danger of worktree/.git and worktree/subdir/.git crossing wires? Are literally nested git repos (whose worktrees are in turn tracked as subdirs by upper-level git repo(s)) a supported/valid model in regards to git.git (NOT git-addons)?

Symptomatically, I have observed the following so far: (1) worktree/.git is "ignoring" (or unaware of) worktree/subdir/.git because it is treating subdir/ as if subdir/.git wasn't there and is not listing subdir/.git as untracked. I'm not sure if this is an unintended side-effect of git ignoring .git(s) automatically, or if having subdir/.git's (w/out having them defined as submodules) is an expected (reasonable/sane/recommended) model for git.git users. (2) running git commands with pwd=worktree/subdir/ acts upon worktree/subdir/.git (subdir/ is regarded as the toplevel of subdir/.git as opposed to a subdir of worktree/.git) and is seemingly oblivious to worktree.git.

I suspect submodules is the "correct" way to implement the effect of nested git repos. That being said, this literal nested git repo is a temporary band-aid and I don't expect it to be propogated, but I do have to deal (react) with it in the meantime. I'm thinking I can manage that and deal with annoyances as they arise, unless there are any unseen landmines I'm not aware of. Please advise.

(I also wouldn't be surprised to hear that this is exactly how submodules really first started in theory or practice.)

Thanks in advance for any feedback.

v/r, neal

My understanding was that such a configuration is essentially tracking the same set of files in two different git repositories. The location of the .git is not important, I could just as easily set the working directory of any git repository to be a folder tracked by another repository.

My concerns would be based primarily on the different repositories trying to act on the same files at the same time. Ignoring the sub-folder completely within the encompassing repository would avoid that, however you might have use cases that prohibit that.

Out of interest, what itch are you scratching by using this model?

Regards,

Andrew Ardill

On 2/9/2012 9:47 PM, Andrew Ardill wrote:

WORKTREE/SUBDIR/ was already tracked by WORKTREE/.git because the files in WORKTREE/SUBDIR/ directly correlate to WORKTREE/ files (ie., WORKTREE/., WORKTREE/SUBDIR2/., WORKTREE/SUBDIR3/.). This is the published model.

(I can only speculate) I think it was intended to ensure that he would only be modifying the WORKTREE/SUBDIR/ files of WORKTREE/.git. He did some sequence of commands with the end result of:

(a) bare repo HISPATH/SUBDIR.git

and

(b1) WORKTREE/.git WORKTREE/SUBDIR/

is now

(b2) WORKTREE/.git WORKTREE/SUBDIR/.git

which means that the files of WORKTREE/SUBDIR are now tracked by WORKTREE/.git and WORKTREE/SUBDIR/.git, as you stated.

Due to a drop-dead short-term deadline, I am being compelled to "just deal with it" (work around the annoyances) unless there is a dire reason it will blow up in our faces. At this point, (b2) is more-or-less an intermediate "integration repo" between (a) and (b1-canonical), and I'm assuming I can just jump thru some hoops to accomplish the integration when the time comes (unless I hear of or step on any landmines).

Now that the newsgroup has confirmed that having "a repo that tracks the worktree of a nested repo" is not a sound model, I can advise against it on a go-forward basis without being concerned that I'm not open to new ideas.

v/r, neal

"Neal Kreitzinger" <neal@rsss.com> writes:

The repository controlled by worktree/.git should behave as if subdir/ does not exist, except that obviously the project cannot have a regular file "subdir" in it. When you chdir to worktree/subdir, everything in there should behave as if worktree/.git directory does not exist.

At least that is the design, and it indeed is how I arrange my primary working tree (I have two "clones" at /git/git.git/ and /git/git.git/Meta, and the latter has a checkout of the "todo" branch), so I would make noises about any breakage for such a layout.

I do not know offhand if an attempt to add files inside subdir to the repository controlled by worktree/.git is always correctly prohibited by the code, though, as our code often forgets to error out "stupid user mistakes", and running "git add subdir/bar" when in worktree/ falls into that category.

And the use of that layout predates the submodules by a large margin. In fact, when people suggest use of submodules when the toplevel and the sublevel do not even need tight version dependencies, some of their use cases might be better supported by using the simply-nested layout without even letting the toplevel be aware of the sublevel.

On 2/9/2012 10:16 PM, Junio C Hamano wrote:

I now see that most of the concept of "a repo worktree path with an o/s subdir containing another repo" is valid provided that the repo is ignoring the worktree of the subdir repo.

In my situation, WORKTREE/.git is tracking the worktree of WORKTREE/SUBDIR/.git. Before WORKTREE/SUBDIR/.git was created, WORKTREE/SUBDIR/ was already being tracked by WORKTREE/.git because WORKTREE/SUBDIR/. directly correlates to the rest of WORKTREE/., WORKTREE/SUBDIR2/., etc. Now that I know that having "a repo tracking the worktree of a nested repo" is not a sound model, I can advise against it on a go-forward basis without being concerned that I am not open to new ideas.

I will keep this in mind when adding submodules.

Thanks!

v/r, neal