On 2/9/2012 10:16 PM, Junio C Hamano wrote:
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 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.
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.
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.
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.
I will keep this in mind when adding submodules.
Thanks!
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