Re: [BUG] Fail to add a module in a subdirectory if module is already cloned

Jens Lehmann [off-list ref] writes:

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?

Am 24.01.2012 22:24, schrieb Junio C Hamano:

Jens Lehmann [off-list ref] writes:

quoted

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?

Nope, it's the fact that the .gitmodules file doesn't contain this name
because the branch was rewound. Please see my post where I proposed the
same change for a slightly different problem:
  http://permalink.gmane.org/gmane.comp.version-control.git/187823
(just fast forward to the first hunk of my diff at the end)

I just didn't realize back then that this is needed even without the
other changes to work properly. The possibly missing cd_to_toplevel is
another problem, the OP started the submodule add in the top level
directory anyways.

Am 24.01.2012 22:44, schrieb Jens Lehmann:

Am 24.01.2012 22:24, schrieb Junio C Hamano:

quoted

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?

Just for the record: I checked that and git-submodule does not set the
SUBDIRECTORY_OK environment variable so every time it is not run in the
top level directory it aborts with:
"You need to run this command from the toplevel of the working tree."