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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html