On Tue, Jun 19, 2018 at 5:56 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > > On Tue, Jun 19, 2018 at 12:36 PM Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > >> > >> On Mon, Jun 18, 2018 at 11:12:15AM -0700, Brandon Williams wrote: > >> > On 06/18, Duy Nguyen wrote: > >> > > This sounds like the submodule specific code in pathspec.c, which has > >> > > been replaced with something else in bw/pathspec-sans-the-index. If > >> > > you have time, try a version without those changes (e.g. v2.13 or > >> > > before) to see if it's a possible culprit. > >> > > >> > I just tested this with v2.13 and saw the same issue. I don't actually > >> > think this ever worked in the way you want it to Heiko. Maybe git add > >> > needs to be taught to be more intelligent when trying to add a submodule > >> > which doesn't exist in the index. > >> > >> That was also my guess, since my feeling is that this is a quite rare > >> use case. Adding submodules alone is not a daily thing, let alone > >> selecting different changes after 'git submodule add'. > >> > >> I also think git could be more intelligent here. > > > > Ah.. the "submodule not registered in index" case. I think I remember > > this (because I remember complaining about it once or two times). > > Definitely agreed that git-add should do the right thing here. > > I am not sure if this even needs to be implemented as "look for the > submodule in the index". Even before submodule was added, we knew > that "git add foo/bar" should reject the request if we find foo is a > symbolic link, and we should do the same when foo/ is a directory > that is the top of a working tree under control of another > repository, no? Exactly. I started with the intention to do something related to the index only to slowly realize that it was not the right place. We traverse directories and stop looking inside a symlink, we can do the same if we realize it's a submodule. -- Duy
