git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [BUG] Fail to add a module in a subdirectory if module is already cloned
@ 2012-01-24 19:11 Jehan Bing
  2012-01-24 21:10 ` Jens Lehmann
  0 siblings, 1 reply; 9+ messages in thread
From: Jehan Bing @ 2012-01-24 19:11 UTC (permalink / raw)
  To: git

Hi,

I'm getting an error if I try to add a module in a subdirectory and that 
module is already cloned.
Here are the steps to reproduce (git 1.7.8.3):

git init module
cd module
echo foo > foo
git add foo
git commit -m "init"
cd ..
git init super
cd super
echo foo > foo
git add foo
git commit -m "init"
git branch b1
git branch b2
git checkout b1
git submodule add ../module lib/module
git commit -m "module"
git checkout b2
rm -rf lib
git submodule add ../module lib/module

The last command returns:
     fatal: Not a git repository: ../.git/modules/lib/module
     Unable to checkout submodule 'lib/module'

The file lib/modules/.git contains:
     gitdir: ../.git/modules/lib/module
(missing an additional "../")

In branch b1, after adding the module, the file contained the full path:
     gitdir: /[...]/super/.git/modules/lib/module
Or contains the correct relative path after checking out b1 later:
     gitdir: ../../.git/modules/lib/module


Regards,
	Jehan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 19:11 [BUG] Fail to add a module in a subdirectory if module is already cloned Jehan Bing
@ 2012-01-24 21:10 ` Jens Lehmann
  2012-01-24 21:13   ` Jens Lehmann
                     ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Jens Lehmann @ 2012-01-24 21:10 UTC (permalink / raw)
  To: Jehan Bing; +Cc: git

Am 24.01.2012 20:11, schrieb Jehan Bing:
> I'm getting an error if I try to add a module in a subdirectory and that module is already cloned.
> Here are the steps to reproduce (git 1.7.8.3):
> 
> git init module
> cd module
> echo foo > foo
> git add foo
> git commit -m "init"
> cd ..
> git init super
> cd super
> echo foo > foo
> git add foo
> git commit -m "init"
> git branch b1
> git branch b2
> git checkout b1
> git submodule add ../module lib/module
> git commit -m "module"
> git checkout b2
> rm -rf lib
> git submodule add ../module lib/module
> 
> The last command returns:
>     fatal: Not a git repository: ../.git/modules/lib/module
>     Unable to checkout submodule 'lib/module'
> 
> The file lib/modules/.git contains:
>     gitdir: ../.git/modules/lib/module
> (missing an additional "../")
> 
> In branch b1, after adding the module, the file contained the full path:
>     gitdir: /[...]/super/.git/modules/lib/module
> Or contains the correct relative path after checking out b1 later:
>     gitdir: ../../.git/modules/lib/module

Thanks for your detailed report, I can reproduce that on current master.

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"
        base_path=$(dirname "$path")

        gitdir=$(git rev-parse --git-dir)

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 21:10 ` Jens Lehmann
@ 2012-01-24 21:13   ` Jens Lehmann
  2012-01-24 21:24   ` Junio C Hamano
  2012-01-24 21:49   ` [PATCH] submodule add: fix breakage when re-adding a deep submodule Jens Lehmann
  2 siblings, 0 replies; 9+ messages in thread
From: Jens Lehmann @ 2012-01-24 21:13 UTC (permalink / raw)
  To: Jehan Bing; +Cc: git

Am 24.01.2012 22:10, schrieb Jens Lehmann:
> The reason for this bug seems to be that in module_clonse() the name is
> not properly initialized for added submodules ...

This should have read "for re-added submodules" ...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 21:10 ` Jens Lehmann
  2012-01-24 21:13   ` Jens Lehmann
@ 2012-01-24 21:24   ` Junio C Hamano
  2012-01-24 21:44     ` Jens Lehmann
  2012-01-24 21:49   ` [PATCH] submodule add: fix breakage when re-adding a deep submodule Jens Lehmann
  2 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2012-01-24 21:24 UTC (permalink / raw)
  To: Jens Lehmann; +Cc: Jehan Bing, git

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 21:24   ` Junio C Hamano
@ 2012-01-24 21:44     ` Jens Lehmann
  2012-01-24 22:14       ` Jens Lehmann
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Lehmann @ 2012-01-24 21:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jehan Bing, git

Am 24.01.2012 22:24, schrieb Junio C Hamano:
> 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?

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH] submodule add: fix breakage when re-adding a deep submodule
  2012-01-24 21:10 ` Jens Lehmann
  2012-01-24 21:13   ` Jens Lehmann
  2012-01-24 21:24   ` Junio C Hamano
@ 2012-01-24 21:49   ` Jens Lehmann
  2012-01-25  1:48     ` Jehan Bing
  2 siblings, 1 reply; 9+ messages in thread
From: Jens Lehmann @ 2012-01-24 21:49 UTC (permalink / raw)
  To: Jehan Bing; +Cc: git, Junio C Hamano

Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there.

When the same submodule is added on a branch where it wasn't present so
far (it is not found in the .gitmodules file), the name is not initialized
from the path as it should. This leads to a wrong path entered in the
gitfile when the .git/modules/<name> directory is found, as this happily
uses the - now empty - name. It then always points only a single directory
up, even if we have a path deeper in the directory hierarchy.

Fix that by initializing the name of the submodule early in module_clone()
if module_name() returned an empty name and add a test to catch that bug.

Reported-by: Jehan Bing <jehan@orb.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---

Am 24.01.2012 22:10, schrieb Jens Lehmann:
> Am 24.01.2012 20:11, schrieb Jehan Bing:
>> I'm getting an error if I try to add a module in a subdirectory and that module is already cloned.
>> Here are the steps to reproduce (git 1.7.8.3):

...

> 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.

Which I now have.


 git-submodule.sh            |    1 +
 t/t7406-submodule-update.sh |    8 ++++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

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"
 	base_path=$(dirname "$path")

 	gitdir=$(git rev-parse --git-dir)
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 33b292b..5b97222 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -611,4 +611,12 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
 	)
 '

+test_expect_success 'submodule add properly re-creates deeper level submodules' '
+	(cd super &&
+	 git reset --hard master &&
+	 rm -rf deeper/ &&
+	 git submodule add ../submodule deeper/submodule
+	)
+'
+
 test_done
-- 
1.7.9.rc2.3.g18574a

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 21:44     ` Jens Lehmann
@ 2012-01-24 22:14       ` Jens Lehmann
  2012-01-24 22:38         ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Lehmann @ 2012-01-24 22:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Am 24.01.2012 22:44, schrieb Jens Lehmann:
> Am 24.01.2012 22:24, schrieb Junio C Hamano:
>> 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."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [BUG] Fail to add a module in a subdirectory if module is already cloned
  2012-01-24 22:14       ` Jens Lehmann
@ 2012-01-24 22:38         ` Junio C Hamano
  0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2012-01-24 22:38 UTC (permalink / raw)
  To: Jens Lehmann; +Cc: git

Jens Lehmann <Jens.Lehmann@web.de> writes:

> 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."

Ah, Ok.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] submodule add: fix breakage when re-adding a deep submodule
  2012-01-24 21:49   ` [PATCH] submodule add: fix breakage when re-adding a deep submodule Jens Lehmann
@ 2012-01-25  1:48     ` Jehan Bing
  0 siblings, 0 replies; 9+ messages in thread
From: Jehan Bing @ 2012-01-25  1:48 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

On 2012-01-24 13:49, Jens Lehmann wrote:
> 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"
>   	base_path=$(dirname "$path")
>
>   	gitdir=$(git rev-parse --git-dir)

That fixed my problem. Thanks Jens.

	Jehan

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-01-25  1:49 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-24 19:11 [BUG] Fail to add a module in a subdirectory if module is already cloned Jehan Bing
2012-01-24 21:10 ` Jens Lehmann
2012-01-24 21:13   ` Jens Lehmann
2012-01-24 21:24   ` Junio C Hamano
2012-01-24 21:44     ` Jens Lehmann
2012-01-24 22:14       ` Jens Lehmann
2012-01-24 22:38         ` Junio C Hamano
2012-01-24 21:49   ` [PATCH] submodule add: fix breakage when re-adding a deep submodule Jens Lehmann
2012-01-25  1:48     ` Jehan Bing

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).