Re: [PATCH] pathspec: remove check_path_for_gitlink

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2016, 07:14 UTC
Message-ID: <xmqq1t5f7j4e.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaO+g7Dm5AgdYGADj=pYDLjV-ALGTxrmwrNGUy1NB=tNg@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 14 quoted lines

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