Re: nested git repos (not submodules)

From: Neal Kreitzinger <nkreitzinger@gmail.com>
Date: Feb 10, 2012, 22:07 UTC
Message-ID: <4F359528.1060603@gmail.com>
In-Reply-To: <CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com>

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

Show 11 quoted lines

> 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.
>

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.

> Out of interest, what itch are you scratching by using this 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