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
