Git Submodule Problem - Bug?

Git Submodule Problem - Bug?

[Manuel Koller]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

Hi

I've encountered strange behavior of git submodule and I cannot think about a way to avoid the problem. I've added a small script that reproduces the problem in the current version of git (1.7.7.3, git-osx-installer).

The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update. 

I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2").  I get the following output:

> ...
> commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date:   Mon Nov 28 17:46:45 2011 +0100
> 
>     initial commit sub1
> commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date:   Mon Nov 28 17:46:45 2011 +0100
> 
>     initial commit sub2

I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.

Best regards,

Manuel


[-- Attachment #2: submodule-bug-minimal-example.bash --]
[-- Type: application/octet-stream, Size: 1491 bytes --]

#/bin/bash

## set -e explicitly
set -e

## set current directory as working directory
wd=`pwd`

## create repositories to be used as submodules
mkdir sub1 sub2 remote
(cd sub1
    git init
    echo "test sub1" >> file
    git add file
    git commit -m "initial commit sub1"
)
git clone --bare sub1 remote/sub1.git
(cd sub2
    git init
    echo "test sub2" >> file
    git add file
    git commit -m "initial commit sub2"
)
git clone --bare sub2 remote/sub2.git

## create super repository
git init --bare remote/super.git
git clone remote/super.git super
(cd super
    git submodule add $wd/remote/sub1.git sub
    git commit -m "Added submodule sub1 as sub"
    git push -u origin master
)

## clone super repository again
## and switch submodule sub1 by sub2
git clone --recursive remote/super.git super2
(cd super2
    ## remote submodule sub
    git config --remove-section submodule.sub
    git rm .gitmodules
    rm -rf sub
    git rm sub
    git commit -m "Removed submodule sub"
    ## add submodule sub2 as sub
    git submodule add $wd/remote/sub2.git sub
    git commit -m "Added submodule sub2 as sub"
    git push
)

## now pull super
(cd super
    git pull
    ## this will fail
    git submodule update --init || echo "submodule update fails, that's ok"
    ## so sync first und update again
    git submodule sync
    git submodule update --init
    ## now sub is corrupt
    (cd sub
	git log master ## this is from sub1
	git log origin/master ## this is from sub2
    )
)

Re: Git Submodule Problem - Bug?

[Thomas Rast]

Manuel Koller wrote:
> 
> The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update. 
> 
> I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2").  I get the following output:
> 
> > ...
> > commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> > Author: Manuel Koller <koller@stat.math.ethz.ch>
> > Date:   Mon Nov 28 17:46:45 2011 +0100
> > 
> >     initial commit sub1
> > commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> > Author: Manuel Koller <koller@stat.math.ethz.ch>
> > Date:   Mon Nov 28 17:46:45 2011 +0100
> > 
> >     initial commit sub2
> 
> I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.

I used the test script at the end (just a testification of your
attachment) to bisect this to the following commit:

    commit 501770e1bb5d132ae4f79aa96715f07f6b84e1f6
    Author: Fredrik Gustafsson <iveqy@iveqy.com>
    Date:   Mon Aug 15 23:17:47 2011 +0200

        Move git-dir for submodules
        
        Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of
        the superproject. This is a step towards being able to delete submodule
        directories without loosing the information from their .git directory
        as that is now stored outside the submodules work tree.
        
        This is done relying on the already existent .git-file functionality.
        When adding or updating a submodule whose git directory is found under
        $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply
        point the .git-file to it and remove the now stale index file from it.
        The index will be recreated by the following checkout.
        
        This patch will not affect already cloned submodules at all.
        
        Tests that rely on .git being a directory have been fixed.
        
        Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
        Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
        Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
        Signed-off-by: Junio C Hamano <gitster@pobox.com>

That is, before 501770 I get sub1/sub2 as Manuel said above.  After
501770 I get sub1/sub1 (!).  I have not been able to reproduce the
sub2/sub2 behavior with any version I tried (1.7.0, 1.7.3.4, 1.7.6,
etc.).  Perhaps there is a configuration setting that changes this?

In any case, since it's -rc4 time and 501770 is set to go into the
release, it would be nice if you could check whether this is indeed
correct/intended.



---- 8< ----
#!/bin/sh

test_description='submodule change bug'
. ./test-lib.sh

## set current directory as working directory
wd=`pwd`

test_expect_success 'set up submodules' '
## create repositories to be used as submodules
mkdir sub1 sub2 remote &&
(cd sub1 &&
    git init &&
    echo "test sub1" >> file &&
    git add file &&
    git commit -m "initial commit sub1"
) &&
git clone --bare sub1 remote/sub1.git &&
(cd sub2 &&
    git init &&
    echo "test sub2" >> file &&
    git add file &&
    git commit -m "initial commit sub2"
) &&
git clone --bare sub2 remote/sub2.git
'

test_expect_success 'set up super-repo' '
## create super repository
git init --bare remote/super.git &&
git clone remote/super.git super &&
(cd super &&
    git submodule add "$wd"/remote/sub1.git sub &&
    git commit -m "Added submodule sub1 as sub" &&
    git push -u origin master
)'

test_expect_success 'make super-repo with sub1->sub2' '
## clone super repository again
## and switch submodule sub1 by sub2
git clone --recursive remote/super.git super2 &&
(cd super2 &&
    ## remote submodule sub
    git config --remove-section submodule.sub &&
    git rm .gitmodules &&
    rm -rf sub &&
    git rm sub &&
    git commit -m "Removed submodule sub" &&
    ## add submodule sub2 as sub
    git submodule add "$wd"/remote/sub2.git sub &&
    git commit -m "Added submodule sub2 as sub" &&
    git push
)
'

test_expect_success 'pull from super2' '
## now pull super
(cd super &&
    git pull &&
    ## this will fail
    if ! git submodule update --init; then
    ## so sync first und update again
        git submodule sync &&
        git submodule update --init
    fi &&
    ## now sub is corrupt
    (cd sub &&
        git log master >log1 && ## this is from sub1
        echo "# next line should be: initial commit from sub1" &&
        grep sub1 log1 &&
        echo "# next line should be: initial commit from sub2" &&
        git log origin/master >log2 && ## this is from sub2
        grep sub2 log2
    )
)
'

test_done

Re: Git Submodule Problem - Bug?

[Fredrik Gustafsson]

On Tue, Nov 29, 2011 at 10:24:01AM +0100, Thomas Rast wrote:
> Manuel Koller wrote:
> > 
> > The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update. 
> > 
> > I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2").  I get the following output:
> > 
> > > ...
> > > commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> > > Author: Manuel Koller <koller@stat.math.ethz.ch>
> > > Date:   Mon Nov 28 17:46:45 2011 +0100
> > > 
> > >     initial commit sub1
> > > commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> > > Author: Manuel Koller <koller@stat.math.ethz.ch>
> > > Date:   Mon Nov 28 17:46:45 2011 +0100
> > > 
> > >     initial commit sub2
> > 
> > I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.
> 
> I used the test script at the end (just a testification of your
> attachment) to bisect this to the following commit:
> 
>     commit 501770e1bb5d132ae4f79aa96715f07f6b84e1f6
>     Author: Fredrik Gustafsson <iveqy@iveqy.com>
>     Date:   Mon Aug 15 23:17:47 2011 +0200
> 
>         Move git-dir for submodules
>         
>         Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of
>         the superproject. This is a step towards being able to delete submodule
>         directories without loosing the information from their .git directory
>         as that is now stored outside the submodules work tree.
>         
>         This is done relying on the already existent .git-file functionality.
>         When adding or updating a submodule whose git directory is found under
>         $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply
>         point the .git-file to it and remove the now stale index file from it.
>         The index will be recreated by the following checkout.
>         
>         This patch will not affect already cloned submodules at all.
>         
>         Tests that rely on .git being a directory have been fixed.
>         
>         Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
>         Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
>         Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
>         Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> That is, before 501770 I get sub1/sub2 as Manuel said above.  After
> 501770 I get sub1/sub1 (!).  I have not been able to reproduce the
> sub2/sub2 behavior with any version I tried (1.7.0, 1.7.3.4, 1.7.6,
> etc.).  Perhaps there is a configuration setting that changes this?
> 
> In any case, since it's -rc4 time and 501770 is set to go into the
> release, it would be nice if you could check whether this is indeed
> correct/intended.
> 
> 
> 
> ---- 8< ----
> #!/bin/sh
> 
> test_description='submodule change bug'
> . ./test-lib.sh
> 
> ## set current directory as working directory
> wd=`pwd`
> 
> test_expect_success 'set up submodules' '
> ## create repositories to be used as submodules
> mkdir sub1 sub2 remote &&
> (cd sub1 &&
>     git init &&
>     echo "test sub1" >> file &&
>     git add file &&
>     git commit -m "initial commit sub1"
> ) &&
> git clone --bare sub1 remote/sub1.git &&
> (cd sub2 &&
>     git init &&
>     echo "test sub2" >> file &&
>     git add file &&
>     git commit -m "initial commit sub2"
> ) &&
> git clone --bare sub2 remote/sub2.git
> '
> 
> test_expect_success 'set up super-repo' '
> ## create super repository
> git init --bare remote/super.git &&
> git clone remote/super.git super &&
> (cd super &&
>     git submodule add "$wd"/remote/sub1.git sub &&
>     git commit -m "Added submodule sub1 as sub" &&
>     git push -u origin master
> )'
> 
> test_expect_success 'make super-repo with sub1->sub2' '
> ## clone super repository again
> ## and switch submodule sub1 by sub2
> git clone --recursive remote/super.git super2 &&
> (cd super2 &&
>     ## remote submodule sub
>     git config --remove-section submodule.sub &&
>     git rm .gitmodules &&
>     rm -rf sub &&
>     git rm sub &&
>     git commit -m "Removed submodule sub" &&
>     ## add submodule sub2 as sub
>     git submodule add "$wd"/remote/sub2.git sub &&
>     git commit -m "Added submodule sub2 as sub" &&
>     git push
> )
> '
> 
> test_expect_success 'pull from super2' '
> ## now pull super
> (cd super &&
>     git pull &&
>     ## this will fail
>     if ! git submodule update --init; then
>     ## so sync first und update again
>         git submodule sync &&
>         git submodule update --init
>     fi &&
>     ## now sub is corrupt
>     (cd sub &&
>         git log master >log1 && ## this is from sub1
>         echo "# next line should be: initial commit from sub1" &&
>         grep sub1 log1 &&
>         echo "# next line should be: initial commit from sub2" &&
>         git log origin/master >log2 && ## this is from sub2
>         grep sub2 log2
>     )
> )
> '
> 
> test_done

This is something I did not thought about when writing that patch. The
reason that this fails is that the part when the first submodule is
removed is no longer complete (as intended). Before this patch
     git config --remove-section submodule.sub &&
     git rm .gitmodules &&
     rm -rf sub &&
Did remove all the data associated with the submodule. That's no longer
the case. The submodule repository is stored in .git/modules and is
still there. When a new submodule (at the same path) is added, the
repository already associated with that path will be used.

If to the three lines above from the test a line that removes the
repository also is added, the test will work:
     git config --remove-section submodule.sub &&
     git rm .gitmodules &&
     rm -rf sub &&
     rm -rf .git/modules/sub &&
     git rm sub &&

The point beeing that 'rm -rf sub' is not longer sufficient to remove a
submodule and its repository. As 'rm -rf' is not a git command, I'm not
sure how this should be solved (or if it should at all).

* Note: the .git/modules/sub is only valid if .git is a git-dir, if it's
  a gitfile, it's not...

-- 
Med vänliga hälsningar
Fredrik Gustafsson

E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74

Re: Git Submodule Problem - Bug?

[Thomas Rast]

Fredrik Gustafsson wrote:
> > [removing a submodule and adding another under the same name
> > confuses git]
> 
> This is something I did not thought about when writing that patch. The
> reason that this fails is that the part when the first submodule is
> removed is no longer complete (as intended). Before this patch
>      git config --remove-section submodule.sub &&
>      git rm .gitmodules &&
>      rm -rf sub &&
> Did remove all the data associated with the submodule. That's no longer
> the case.

So maybe the right questions to ask would be: what's the *official*
way of removing a submodule completely?  Do we support overwriting
submodules in the way Manuel wanted to?  Why not? :-)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Git Submodule Problem - Bug?

[Fredrik Gustafsson]

On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:
> So maybe the right questions to ask would be: what's the *official*
> way of removing a submodule completely?  Do we support overwriting
> submodules in the way Manuel wanted to?  Why not? :-)

I suggest that we add a command for that;
git submodule remove <submodule>

That should be pretty easy and straight forward to do. However I would
like to hear what Jens, Heiko and/or Junio has to say before starting to
implement it.

-- 
Med vänliga hälsningar
Fredrik Gustafsson

E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74

Re: Git Submodule Problem - Bug?

[Jens Lehmann]

Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:
> On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:
>> So maybe the right questions to ask would be: what's the *official*
>> way of removing a submodule completely?  Do we support overwriting
>> submodules in the way Manuel wanted to?  Why not? :-)
> 
> I suggest that we add a command for that;
> git submodule remove <submodule>

Hmm, to me it looks like the problem is in "git submodule add". It
doesn't check if the submodule repo it finds in .git/modules matches
the one the user wants to create. So we end up reviving the first
submodule although the user wants to use a completely different repo.

One solution could be to only let "git submodule update" revive
submodules from .git/modules and make "git submodule add" error out
if it finds the git directory of a submodule with the same name in
.git/modules. But currently there is no way to tell "git submodule add"
to use a different submodule name (it always uses the path as a name),
so we might have to add an option to do that and tell the user in the
error message how he can add a different submodule under the same
path.

Another solution could be that "git submodule add" detects that a
submodule with the name "sub" did exist and chooses a different name
(say "sub2") for the the new one. Then the user wouldn't have to
cope with the problem himself.

Re: Git Submodule Problem - Bug?

[Manuel Koller]

Thanks for taking my problem seriously.

On 29.11.2011, at 18:42, Jens Lehmann wrote:

> Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:
>> On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:
>>> So maybe the right questions to ask would be: what's the *official*
>>> way of removing a submodule completely?  Do we support overwriting
>>> submodules in the way Manuel wanted to?  Why not? :-)
>> 
>> I suggest that we add a command for that;
>> git submodule remove <submodule>
> 
> Hmm, to me it looks like the problem is in "git submodule add". It
> doesn't check if the submodule repo it finds in .git/modules matches
> the one the user wants to create. So we end up reviving the first
> submodule although the user wants to use a completely different repo.

In have wrote a workaround for the problem i posted that goes into this direction. I just check whether the url has changed and remove the submodule by hand if it did. See https://github.com/kollerma/git-submodule-tools if you're interested (its in git-fix-submodules).

> One solution could be to only let "git submodule update" revive
> submodules from .git/modules and make "git submodule add" error out
> if it finds the git directory of a submodule with the same name in
> .git/modules. But currently there is no way to tell "git submodule add"
> to use a different submodule name (it always uses the path as a name),
> so we might have to add an option to do that and tell the user in the
> error message how he can add a different submodule under the same
> path.
> 
> Another solution could be that "git submodule add" detects that a
> submodule with the name "sub" did exist and chooses a different name
> (say "sub2") for the the new one. Then the user wouldn't have to
> cope with the problem himself.

What is the purpose of having two different submodules in the same path? Identifying the submodule by url however would probably make things considerably faster. At least in my case, since I have checked out different branches of the same repo at different paths as submodules. 

Re: Git Submodule Problem - Bug?

[Junio C Hamano]

Manuel Koller <koller.manuel@gmail.com> writes:

> In have wrote a workaround for the problem i posted that goes into this
> direction. I just check whether the url has changed and remove the
> submodule by hand if it did.

... which might be wrong, depending on how you implement it, so be careful
(see below).

> ...
> What is the purpose of having two different submodules in the same path?
> Identifying the submodule by url however would probably make things
> considerably faster...

There are three primary things involved when talking about a submodule in
a superproject. Its name, its path in the superproject hierarchy, and its
URL (if it is foreign). The canonical example used when discussing the
design of Git submodule support is to imagine your superproject that is
about a small router that has a kernel component as a submodule that lives
in kernel/ hierarchy (your userland may live elsewhere in the tree, either
as a submodule bound at src/ hierarchy or contained in the superproject
itself and it does not make a difference).

You may had two major versions of your product. v1.0 line used to use BSD
kernels, and v2.0 line with linux-2.6 kernels. Even though a checkout of
any version of your superproject has a submodule bound at its kernel/
directory, the logical identity of the submodule used in your v1.0 line of
product and v2.0 line are different. You can differenciate them by giving
them different names, say 'kernel' and 'linux-kernel' [*1*]. When you
checkout the v1.0 tag, kernel/ directory should be populated by the
submodule that house the BSD kernel. When you checkout the v2.0 tag, it
should house the Linux 2.6 kernel.

Now, your v3.0 line will still use linux-2.6 (and now linux-3.0)
kernel. Logically, the kernel project is the same thing. linux-3.0 is just
a continuation of linux-2.6 series and maintained in the *logically* same
upstream repository. However, the repository location has recently changed
and now lives in

    http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

even though it used to be linux-2.6.git in the same hierarchy [*2*]. The
name of the submodule ('linux-kernel') does not have to change, as the
repository in the new location has all the history for linux-2.6 kernel as
well. The URL mapping recorded in .gitmodules in-tree from the submodule
name to the location however needs to change [*3*]. Ideally (I do not
think the current "git submodule" implementation does this), there should
be a more automated way to optionally allow switching the upstream URL of
the 'linux-kernel' subproject bound at kernel/ directory when you switch
between commits in the v2.0 series and in the v3.0 series of the
superproject [*3*], so that the user can say "Yes, I know linux.git URL
contains everything needed from linux-2.6.git URL, so just update the
submodule's upstream URL to linux.git one, and keep it like so; there is
no need to use the older URL even when I check out v2.0 from the
superproject" or "Notice when the URL recorded in .gitmodules for this
project changes when I check out a different version of the superproject,
and use the old URL to update the submodule when I check out the old
version of the superproject".

Even though it is an ancient design discussion, this thread is worth a
read before discussing anything about submodules:

  http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47498

not because the ideas that were discussed but not implemented in the
current "git submodule" are all good things that should be added, but
because the discussion shows what kind of considerations need to go into
the design.


[Footnotes]

*1* In the ideal world, you would have called it 'bsd' back in your v1.0
days with a foresight that someday you would switch to 'linux', but it is
likely you would not have been perfect.

*2* You can still access it as linux-2.6.git because k.org is trying to be
nice to its users, but that is besides the point.

*3* It becomes relevant if you imagine a case where the old linux-2.6.git
repository at k.org were left frozen at the last version of the 2.6 series
and the new history is only available in linux.git repository.

Re: Re: Git Submodule Problem - Bug?

[Heiko Voigt]

Hi,

On Tue, Nov 29, 2011 at 06:42:03PM +0100, Jens Lehmann wrote:
> Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:
> > On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:
> >> So maybe the right questions to ask would be: what's the *official*
> >> way of removing a submodule completely?  Do we support overwriting
> >> submodules in the way Manuel wanted to?  Why not? :-)
> > 
> > I suggest that we add a command for that;
> > git submodule remove <submodule>
> 
> Hmm, to me it looks like the problem is in "git submodule add". It
> doesn't check if the submodule repo it finds in .git/modules matches
> the one the user wants to create. So we end up reviving the first
> submodule although the user wants to use a completely different repo.
> 
> One solution could be to only let "git submodule update" revive
> submodules from .git/modules and make "git submodule add" error out
> if it finds the git directory of a submodule with the same name in
> .git/modules. But currently there is no way to tell "git submodule add"
> to use a different submodule name (it always uses the path as a name),
> so we might have to add an option to do that and tell the user in the
> error message how he can add a different submodule under the same
> path.

I think this is the way to go. We teached submodule add to revive a
local submodule. Further thinking about it this is probably not what the
users wants in most cases. For update its the right thing but for add we
should probably tell the user that there is already a local submodule in
the way and give him the option to take it or that he should remove it.

> Another solution could be that "git submodule add" detects that a
> submodule with the name "sub" did exist and chooses a different name
> (say "sub2") for the the new one. Then the user wouldn't have to
> cope with the problem himself.

In my opinion this is too much automatism. We could prompt for a new
name to support the user but I do not think this mechanism should be
automatic.

How about this:

The user issues 'git submodule add foo' and we discover that there is
already a local clone under the name foo. Git then asks something like
this

	Error when adding: There is already a local submodule under the
	name 'foo'.

	You can either rename the submodule to be added to a different
	name or manually remove the local clone underneath
	.git/modules/foo. If you want to remove the local clone please
	quit now.

	We strongly suggest that you give each submodule a unique name.
	Note: This name is independent from the path it is bound to.

	What do you want me to do ([r]ename it, [Q]uit) ?

When the user chooses 'rename' git will prompt for a new name.

If we are going to support the remove use case with add we additionally
need some logic to deal with it during update (which is not supported
yet AFAIK). But we probably need this support anyway since between
removal and adding a new submodule under the same can be a long time.
If users switch between such ancient history and the new history we
would have the same conflict.

We could of course just error out and tell the user that he has to give
the submodule an uniqe name. If the user does not do so leave it to him
to deal with the situation manually.

What do you think?

Cheers Heiko

Re: Re: Git Submodule Problem - Bug?

[Manuel Koller]

> How about this:
>
> The user issues 'git submodule add foo' and we discover that there is
> already a local clone under the name foo. Git then asks something like
> this
>
>        Error when adding: There is already a local submodule under the
>        name 'foo'.
>
>        You can either rename the submodule to be added to a different
>        name or manually remove the local clone underneath
>        .git/modules/foo. If you want to remove the local clone please
>        quit now.
>
>        We strongly suggest that you give each submodule a unique name.
>        Note: This name is independent from the path it is bound to.
>
>        What do you want me to do ([r]ename it, [Q]uit) ?
>
> When the user chooses 'rename' git will prompt for a new name.
>
> If we are going to support the remove use case with add we additionally
> need some logic to deal with it during update (which is not supported
> yet AFAIK). But we probably need this support anyway since between
> removal and adding a new submodule under the same can be a long time.
> If users switch between such ancient history and the new history we
> would have the same conflict.
>
> We could of course just error out and tell the user that he has to give
> the submodule an uniqe name. If the user does not do so leave it to him
> to deal with the situation manually.
>
> What do you think?
>
> Cheers Heiko

Prompt to choose another name would be fine I guess - but it solves
the problem only if the submodule has been initialized already. There
could be a submodule of the same name in another branch, which I
haven't checked out yet, for example. The user would have to be forced
choose a unique name for every submodule.

Anyway, it seems impossible to handle a name clash automatically,
since there are good reasons to have different urls for the same
submodule. Having read the thread linked by Junio, the only way out
seems to be a kind of url rewrite scheme and using the url as name.
Doesn't it solve all the problems?

- the url is more or less unique (there are problems now if we have to
different submodules at the same path, which is much more likely to
happen than a different repository at the same url some time in the
future)
- after a change of the submodule's url, we can still check out old
commits in a comfortable way
- we could have the same submodule at different paths, but downloaded only once
- the user is not forced to do anything, but the .gitmodule config can
still be overruled if necessary

Re: Git Submodule Problem - Bug?

[Jens Lehmann]

Am 07.12.2011 09:21, schrieb Manuel Koller:
>> How about this:
>>
>> The user issues 'git submodule add foo' and we discover that there is
>> already a local clone under the name foo. Git then asks something like
>> this
>>
>>        Error when adding: There is already a local submodule under the
>>        name 'foo'.
>>
>>        You can either rename the submodule to be added to a different
>>        name or manually remove the local clone underneath
>>        .git/modules/foo. If you want to remove the local clone please
>>        quit now.
>>
>>        We strongly suggest that you give each submodule a unique name.
>>        Note: This name is independent from the path it is bound to.
>>
>>        What do you want me to do ([r]ename it, [Q]uit) ?
>>
>> When the user chooses 'rename' git will prompt for a new name.
>>
>> If we are going to support the remove use case with add we additionally
>> need some logic to deal with it during update (which is not supported
>> yet AFAIK). But we probably need this support anyway since between
>> removal and adding a new submodule under the same can be a long time.
>> If users switch between such ancient history and the new history we
>> would have the same conflict.
>>is_submodule_modified()
>> We could of course just error out and tell the user that he has to give
>> the submodule an uniqe name. If the user does not do so leave it to him
>> to deal with the situation manually.
>>
>> What do you think?
>>
>> Cheers Heiko
> 
> Prompt to choose another name would be fine I guess - but it solves
> the problem only if the submodule has been initialized already. There
> could be a submodule of the same name in another branch, which I
> haven't checked out yet, for example. The user would have to be forced
> choose a unique name for every submodule.

Which seems pretty much impossible in a distributed system ...

> Anyway, it seems impossible to handle a name clash automatically,
> since there are good reasons to have different urls for the same
> submodule.> Having read the thread linked by Junio, the only way out
> seems to be a kind of url rewrite scheme and using the url as name.
> Doesn't it solve all the problems?
> 
> - the url is more or less unique (there are problems now if we have to
> different submodules at the same path, which is much more likely to
> happen than a different repository at the same url some time in the
> future)
> - after a change of the submodule's url, we can still check out old
> commits in a comfortable way
> - we could have the same submodule at different paths, but downloaded only once
> - the user is not forced to do anything, but the .gitmodule config can
> still be overruled if necessary

Hmm, using the URL has the downside that when one URL is just a fork of
the other we might have most of the repo duplicated in the .git/modules
directory ... but if it solves the problem of having a totally different
submodule cloned into the same path it might be worth it.