From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 24 Jan 2012 21:24:15 GMT
Subject: Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
Message-ID: <7vhazk3ibk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F1F1E5F.2030509@web.de>

Jens Lehmann <Jens.Lehmann@web.de> 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?