On Thu, May 5, 2016 at 11:21 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> 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.
>
> 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.
--
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