Subject: nested git repos (not submodules)

From: "Neal Kreitzinger" <[email-masked]>
Date: Thu, 9 Feb 2012 20:34:42 -0600

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