From: Stefan Beller Date: Fri, 06 May 2016 06:58:52 GMT Subject: Re: [PATCH] pathspec: remove check_path_for_gitlink Message-ID: In-Reply-To: On Thu, May 5, 2016 at 11:21 PM, Junio C Hamano wrote: > Junio C Hamano 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 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.