Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > The reason for this bug seems to be that in module_clonse() the name is > not properly initialized for added submodules (it gets set to the path > later), so the correct amount of leading "../"s for the git directory > is not computed properly. The attached diff fixes that for me, I will > send a patch as soon as I have extended a test case for this breakage. > > diff --git a/git-submodule.sh b/git-submodule.sh > index 3adab93..9bb2e13 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -131,6 +131,7 @@ module_clone() > gitdir= > gitdir_base= > name=$(module_name "$path" 2>/dev/null) > + test -n "$name" || name="$path" This somehow smells like sweeping a problem under the rug. Why doesn't module_name find the already registered path in the first place? I see "module_name" calls "git config -f .gitmodules" and I do not see any cd_to_toplevel in git-submodule.sh that would ensure this call to access the gitmodules file at the top-level of the superproject. Is that the real reason why it is not finding what it should be finding? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html