On Thu, May 5, 2016 at 4:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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.
--
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