Stefan Beller <sbeller@xxxxxxxxxx> writes:
> There are 2 fundamental cases though.
> (1) The bug we're talking about (as explained in that blog), refers to 2
> independent repositories, whose work trees are nested
> (2) You seemed to bring in the notion that the nested repo is considered
> a submodule of the outer repo, i.e. they have a relationship.
>
> I don't mind (1). It's a neat hack as these 2 repos are totally unrelated
> (except for the working tree in the file system being the same files).
> You could also achieve a similar handling by hardlinking gitk-git/gitk
> and git.git/gitk-git/gitk.
>
> In (2), we have a gitlink, which by definition takes up the whole directory.
> So any file in that directory in the file system which represents the root of
> the submodule should belong to the submodule.
I certainly didn't mean to "bring in the notion" as if it is
something entirely alien to the discussion. Before you "git add",
it may be a "nested independent" repository, but that is merely a
submodule that is untracked, yet to be added. Just like tracked
files were once untracked before they got added, these are possible
submodules that happened to be not tracked yet.
I do not see there is any difference between the two at all.
If deep/in is a repository yet to be added as a submodule,
$ git add deep/in/the/tree/is-a-leaf.txt
$ git add deep/in
in the hypothetical "git add A is equivalent to git -C $(dirname A)
add $(basename A)" world should behave the same regardless of the
order of these two commands (otherwise the behaviour is way too
confusing).
--
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