On Thu, 15 Sep 2016, Junio C Hamano wrote: > >> which then stops without even looking at other submodules. > >> I think it would be more logical to make it a 'warning:' not a 'fatal:' and > >> proceed. > Making "git submodule" listing to continue from that point may be > one thing, but do we have a sensible way in "git submodule add" to > allow the user to recover from this condition? That is, "git add" > is a right way to tell the core level that there is a gitlink, but > as Yaroslav correctly observed in the early part of his message, > having that gitlink alone is not good enough for the world view of > "git submodule" that sits at higher-layer. And the usual way to > tell the submodule layer that there is a submodule is with "git > submodule add", but > $ git init top > $ cd top > $ git commit --allow-empty -m 'initial in top' > $ git init sub > $ git -C sub commit --allow-empty -m 'initial in sub' > $ git add sub > $ git submodule > fatal: no submodule mapping found in .gitmodules for path 'sub' > $ git submodule add ./sub sub > 'sub' already exists in the index > $ git submodule add -f ./sub sub > 'sub' already exists in the index FWIW I could have sworn that I have tried to 'submodule add' it and it worked... but pragmatically I just did edit .gitmodules, added the record for it, committed it, and then iirc git submodule update --init which seemed to make git happy... FTR: $> git submodule add ./sub ./sub 'sub' already exists in the index $> git submodule add ./sub/ ./sub/ 'sub' already exists in the index $> vim .gitmodules $> git add .gitmodules cached/staged changes: .gitmodules | 4 ++++ sub | 1 + $> git submodule update --init Submodule 'sub' (/tmp/111/top/sub) registered for path 'sub' cached/staged changes: .gitmodules | 4 ++++ sub | 1 + $> git commit -m 'added finally' [master aa6d912] added finally 2 files changed, 5 insertions(+) create mode 100644 .gitmodules create mode 160000 sub $> git submodule 6f574b298ef51aebd36daafad450a3e38802ca03 sub (heads/master) > I highly suspect that the user will then get stuck at this point, > after trying to "submodule add" and then even attempting to force > it. > I think that is a more pressing thing to address. Once we make it > easier for the user to bring a half-initialized submodule properly > into the world view of the submodule subsystem, we would have to > worry about the reported failure case even less and you do not need > to pile on workaround options to let things continue in a state that > is half-broken (that is, in a state that is perfectly sane to the > core layer, but is not liked by the submodule layer). do you foresee any unpleasant side-effects from above manual editing .gitmodules/submodule update --init ? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik