Re: [PATCH] pathspec: remove check_path_for_gitlink

[Stefan Beller <sbeller@google.com>]

On Thu, May 5, 2016 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> That was my first reaction as well. However after a while of thought I actually
>> like that bug. Consider the possibilities how gitk/git-gui or other subsystems
>> can be developed. When accepting a patch for that you can either apply the
>> patch in the outer or inner repository, depending on what the sender used.
>>
>> I am not so sure if it is a bug plain and simple, but devolved into a
>> "feature" now.
>
> I'd freely admit that I have not considered its possible upsides at
> all.  When deep/in/ is an unrelated repository, and running either
>
>     git add deep/in/the
>     git add deep/in/the/tree

I think that doesn't work (I did not test), but the crucial part is to add
a trailing '/'. E.g.  `git add deep/in/the/` adds the 'the/**' tree of
the nested
repository.

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

Yes.

    git add deep/in # adds a submodule

however:

    git add deep/in/ # adds all files of the sub-"repo"  as indpendent files
    git commit -a -m "new files"
    git -C deep/in reset --hard HEAD^
    git diff
    # shows a difference in deep/in/the/tree/is-a-leaf.txt

>
> And that is enough for me to declare that it is not worth my time to
> consider possible upside of that hole.  Can you tell offhand what
> would happen if you do "git add deep" (before adding deep/in as a
> submodule) without experimenting?
>

Not really. My expectation is to add everything *but* the deep/in/ repo
as this is not exercising the bug/feature.