Re: [PATCH] pathspec: remove check_path_for_gitlink

From: Stefan Beller <sbeller@google.com>
Date: May 6, 2016, 06:58 UTC
Message-ID: <CAGZ79kaO+g7Dm5AgdYGADj=pYDLjV-ALGTxrmwrNGUy1NB=tNg@mail.gmail.com>
In-Reply-To: <xmqq60ur7ll3.fsf@gitster.mtv.corp.google.com>

On Thu, May 5, 2016 at 11:21 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> When deep/in/ is an unrelated repository, and running either
>>
>>     git add deep/in/the
>>     git add deep/in/the/tree
>>
>> would add deep/in/the/tree/is-a-leaf.txt to my index, but if I did
>>
>>     git add deep/in
>>
>> I'd lose that and suddenly everything there turns into a submodule.
>
> Also, I recall that you floated an idea to declare that
>
>     git add deep/in/the/tree/is-a-leaf.txt
>
> must always behave as if this is done instead:
>
>     git -C deep/in/the/tree/ add is-a-leaf.txt

In a different thread, yeah. I am not sure about that any more.

Show 8 quoted lines

>
> Even though I am not a huge fan of an operation that crosses module
> boundaries, I think that is a sensible semantics of a "cross module
> boundary operation" (the actual implementation should not be
> iterating over pathspecs and chdir(2)ing around for each and every
> one of them, though), if we need "cross module boundary operation"
> in order to support end users working on a project with one or more
> submodules at the same time.

I agree.

>
> But treating the bug under discussion as a "feature" will destroy
> that future.

The bug under discussion was blogged about in 2010 and still persists. I'll try to find out if people actually use it.

If that bug was fixed, but I still wanted to enjoy the upsides of it, I could to that with pointing core.worktree into deep/in/tree. e.g. I have git.git and gitk-git as separate repositories, then I could still do a

    GIT_DIR=gitk-git/.git git -C git.git/gitk-git git checkout
<sha1-of-gitk-repo>

This looks more complicated than this bug/feature though.

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.