Re: [PATCH] pathspec: remove check_path_for_gitlink

On Thu, May 5, 2016 at 11:21 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

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.