Re: [PATCH] pathspec: remove check_path_for_gitlink

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> 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).