On 2/9/2012 9:47 PM, Andrew Ardill wrote:
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
--
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