{"thread":{"id":"29037","subject":"Git Submodule Problem - Bug?","startedAt":"2011-11-28T17:13:36Z","lastAt":"2011-12-07T21:56:54Z","messageCount":11,"participants":["Manuel Koller","Thomas Rast","Fredrik Gustafsson","Jens Lehmann","Junio C Hamano","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180052","messageId":"38AE3033-6902-48AA-819B-DB4083F1F8EF@gmail.com","threadId":"29037","inReplyTo":null,"subject":"Git Submodule Problem - Bug?","fromName":"Manuel Koller","fromEmail":"koller.manuel@gmail.com","sentAt":"2011-11-28T17:13:36Z","receivedAt":"2011-11-28T17:13:36Z","isPatch":false,"sender":{"key":"koller.manuel@gmail.com","avatar":null},"body":"Hi\n\nI'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).\n\nThe 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. \n\nI 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:\n\n> ...\n> commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39\n> Author: Manuel Koller <koller@stat.math.ethz.ch>\n> Date:   Mon Nov 28 17:46:45 2011 +0100\n> \n>     initial commit sub1\n> commit 346fe6bd9e7957f10c5e833bb1155153379da41c\n> Author: Manuel Koller <koller@stat.math.ethz.ch>\n> Date:   Mon Nov 28 17:46:45 2011 +0100\n> \n>     initial commit sub2\n\nI 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.\n\nBest regards,\n\nManuel\n\n"},{"id":"180077","messageId":"201111291024.01230.trast@student.ethz.ch","threadId":"29037","inReplyTo":"38AE3033-6902-48AA-819B-DB4083F1F8EF@gmail.com","subject":"Re: Git Submodule Problem - Bug?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-11-29T09:24:01Z","receivedAt":"2011-11-29T09:24:01Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Manuel Koller wrote:\n> \n> 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. \n> \n> 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:\n> \n> > ...\n> > commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39\n> > Author: Manuel Koller <koller@stat.math.ethz.ch>\n> > Date:   Mon Nov 28 17:46:45 2011 +0100\n> > \n> >     initial commit sub1\n> > commit 346fe6bd9e7957f10c5e833bb1155153379da41c\n> > Author: Manuel Koller <koller@stat.math.ethz.ch>\n> > Date:   Mon Nov 28 17:46:45 2011 +0100\n> > \n> >     initial commit sub2\n> \n> 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.\n\nI used the test script at the end (just a testification of your\nattachment) to bisect this to the following commit:\n\n    commit 501770e1bb5d132ae4f79aa96715f07f6b84e1f6\n    Author: Fredrik Gustafsson <iveqy@iveqy.com>\n    Date:   Mon Aug 15 23:17:47 2011 +0200\n\n        Move git-dir for submodules\n        \n        Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of\n        the superproject. This is a step towards being able to delete submodule\n        directories without loosing the information from their .git directory\n        as that is now stored outside the submodules work tree.\n        \n        This is done relying on the already existent .git-file functionality.\n        When adding or updating a submodule whose git directory is found under\n        $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply\n        point the .git-file to it and remove the now stale index file from it.\n        The index will be recreated by the following checkout.\n        \n        This patch will not affect already cloned submodules at all.\n        \n        Tests that rely on .git being a directory have been fixed.\n        \n        Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>\n        Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>\n        Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>\n        Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nThat is, before 501770 I get sub1/sub2 as Manuel said above.  After\n501770 I get sub1/sub1 (!).  I have not been able to reproduce the\nsub2/sub2 behavior with any version I tried (1.7.0, 1.7.3.4, 1.7.6,\netc.).  Perhaps there is a configuration setting that changes this?\n\nIn any case, since it's -rc4 time and 501770 is set to go into the\nrelease, it would be nice if you could check whether this is indeed\ncorrect/intended.\n\n\n\n---- 8< ----\n#!/bin/sh\n\ntest_description='submodule change bug'\n. ./test-lib.sh\n\n## set current directory as working directory\nwd=`pwd`\n\ntest_expect_success 'set up submodules' '\n## create repositories to be used as submodules\nmkdir sub1 sub2 remote &&\n(cd sub1 &&\n    git init &&\n    echo \"test sub1\" >> file &&\n    git add file &&\n    git commit -m \"initial commit sub1\"\n) &&\ngit clone --bare sub1 remote/sub1.git &&\n(cd sub2 &&\n    git init &&\n    echo \"test sub2\" >> file &&\n    git add file &&\n    git commit -m \"initial commit sub2\"\n) &&\ngit clone --bare sub2 remote/sub2.git\n'\n\ntest_expect_success 'set up super-repo' '\n## create super repository\ngit init --bare remote/super.git &&\ngit clone remote/super.git super &&\n(cd super &&\n    git submodule add \"$wd\"/remote/sub1.git sub &&\n    git commit -m \"Added submodule sub1 as sub\" &&\n    git push -u origin master\n)'\n\ntest_expect_success 'make super-repo with sub1->sub2' '\n## clone super repository again\n## and switch submodule sub1 by sub2\ngit clone --recursive remote/super.git super2 &&\n(cd super2 &&\n    ## remote submodule sub\n    git config --remove-section submodule.sub &&\n    git rm .gitmodules &&\n    rm -rf sub &&\n    git rm sub &&\n    git commit -m \"Removed submodule sub\" &&\n    ## add submodule sub2 as sub\n    git submodule add \"$wd\"/remote/sub2.git sub &&\n    git commit -m \"Added submodule sub2 as sub\" &&\n    git push\n)\n'\n\ntest_expect_success 'pull from super2' '\n## now pull super\n(cd super &&\n    git pull &&\n    ## this will fail\n    if ! git submodule update --init; then\n    ## so sync first und update again\n        git submodule sync &&\n        git submodule update --init\n    fi &&\n    ## now sub is corrupt\n    (cd sub &&\n        git log master >log1 && ## this is from sub1\n        echo \"# next line should be: initial commit from sub1\" &&\n        grep sub1 log1 &&\n        echo \"# next line should be: initial commit from sub2\" &&\n        git log origin/master >log2 && ## this is from sub2\n        grep sub2 log2\n    )\n)\n'\n\ntest_done\n"},{"id":"180079","messageId":"20111129101546.GB2829@kolya","threadId":"29037","inReplyTo":"201111291024.01230.trast@student.ethz.ch","subject":"Re: Git Submodule Problem - Bug?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-11-29T10:15:46Z","receivedAt":"2011-11-29T10:15:46Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Nov 29, 2011 at 10:24:01AM +0100, Thomas Rast wrote:\n> Manuel Koller wrote:\n> > \n> > 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. \n> > \n> > 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:\n> > \n> > > ...\n> > > commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39\n> > > Author: Manuel Koller <koller@stat.math.ethz.ch>\n> > > Date:   Mon Nov 28 17:46:45 2011 +0100\n> > > \n> > >     initial commit sub1\n> > > commit 346fe6bd9e7957f10c5e833bb1155153379da41c\n> > > Author: Manuel Koller <koller@stat.math.ethz.ch>\n> > > Date:   Mon Nov 28 17:46:45 2011 +0100\n> > > \n> > >     initial commit sub2\n> > \n> > 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.\n> \n> I used the test script at the end (just a testification of your\n> attachment) to bisect this to the following commit:\n> \n>     commit 501770e1bb5d132ae4f79aa96715f07f6b84e1f6\n>     Author: Fredrik Gustafsson <iveqy@iveqy.com>\n>     Date:   Mon Aug 15 23:17:47 2011 +0200\n> \n>         Move git-dir for submodules\n>         \n>         Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of\n>         the superproject. This is a step towards being able to delete submodule\n>         directories without loosing the information from their .git directory\n>         as that is now stored outside the submodules work tree.\n>         \n>         This is done relying on the already existent .git-file functionality.\n>         When adding or updating a submodule whose git directory is found under\n>         $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply\n>         point the .git-file to it and remove the now stale index file from it.\n>         The index will be recreated by the following checkout.\n>         \n>         This patch will not affect already cloned submodules at all.\n>         \n>         Tests that rely on .git being a directory have been fixed.\n>         \n>         Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>\n>         Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>\n>         Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>\n>         Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> \n> That is, before 501770 I get sub1/sub2 as Manuel said above.  After\n> 501770 I get sub1/sub1 (!).  I have not been able to reproduce the\n> sub2/sub2 behavior with any version I tried (1.7.0, 1.7.3.4, 1.7.6,\n> etc.).  Perhaps there is a configuration setting that changes this?\n> \n> In any case, since it's -rc4 time and 501770 is set to go into the\n> release, it would be nice if you could check whether this is indeed\n> correct/intended.\n> \n> \n> \n> ---- 8< ----\n> #!/bin/sh\n> \n> test_description='submodule change bug'\n> . ./test-lib.sh\n> \n> ## set current directory as working directory\n> wd=`pwd`\n> \n> test_expect_success 'set up submodules' '\n> ## create repositories to be used as submodules\n> mkdir sub1 sub2 remote &&\n> (cd sub1 &&\n>     git init &&\n>     echo \"test sub1\" >> file &&\n>     git add file &&\n>     git commit -m \"initial commit sub1\"\n> ) &&\n> git clone --bare sub1 remote/sub1.git &&\n> (cd sub2 &&\n>     git init &&\n>     echo \"test sub2\" >> file &&\n>     git add file &&\n>     git commit -m \"initial commit sub2\"\n> ) &&\n> git clone --bare sub2 remote/sub2.git\n> '\n> \n> test_expect_success 'set up super-repo' '\n> ## create super repository\n> git init --bare remote/super.git &&\n> git clone remote/super.git super &&\n> (cd super &&\n>     git submodule add \"$wd\"/remote/sub1.git sub &&\n>     git commit -m \"Added submodule sub1 as sub\" &&\n>     git push -u origin master\n> )'\n> \n> test_expect_success 'make super-repo with sub1->sub2' '\n> ## clone super repository again\n> ## and switch submodule sub1 by sub2\n> git clone --recursive remote/super.git super2 &&\n> (cd super2 &&\n>     ## remote submodule sub\n>     git config --remove-section submodule.sub &&\n>     git rm .gitmodules &&\n>     rm -rf sub &&\n>     git rm sub &&\n>     git commit -m \"Removed submodule sub\" &&\n>     ## add submodule sub2 as sub\n>     git submodule add \"$wd\"/remote/sub2.git sub &&\n>     git commit -m \"Added submodule sub2 as sub\" &&\n>     git push\n> )\n> '\n> \n> test_expect_success 'pull from super2' '\n> ## now pull super\n> (cd super &&\n>     git pull &&\n>     ## this will fail\n>     if ! git submodule update --init; then\n>     ## so sync first und update again\n>         git submodule sync &&\n>         git submodule update --init\n>     fi &&\n>     ## now sub is corrupt\n>     (cd sub &&\n>         git log master >log1 && ## this is from sub1\n>         echo \"# next line should be: initial commit from sub1\" &&\n>         grep sub1 log1 &&\n>         echo \"# next line should be: initial commit from sub2\" &&\n>         git log origin/master >log2 && ## this is from sub2\n>         grep sub2 log2\n>     )\n> )\n> '\n> \n> test_done\n\nThis is something I did not thought about when writing that patch. The\nreason that this fails is that the part when the first submodule is\nremoved is no longer complete (as intended). Before this patch\n     git config --remove-section submodule.sub &&\n     git rm .gitmodules &&\n     rm -rf sub &&\nDid remove all the data associated with the submodule. That's no longer\nthe case. The submodule repository is stored in .git/modules and is\nstill there. When a new submodule (at the same path) is added, the\nrepository already associated with that path will be used.\n\nIf to the three lines above from the test a line that removes the\nrepository also is added, the test will work:\n     git config --remove-section submodule.sub &&\n     git rm .gitmodules &&\n     rm -rf sub &&\n     rm -rf .git/modules/sub &&\n     git rm sub &&\n\nThe point beeing that 'rm -rf sub' is not longer sufficient to remove a\nsubmodule and its repository. As 'rm -rf' is not a git command, I'm not\nsure how this should be solved (or if it should at all).\n\n* Note: the .git/modules/sub is only valid if .git is a git-dir, if it's\n  a gitfile, it's not...\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\nE-post: iveqy@iveqy.com\nTel. nr.: 0733 60 82 74\n"},{"id":"180081","messageId":"201111291125.41943.trast@student.ethz.ch","threadId":"29037","inReplyTo":"20111129101546.GB2829@kolya","subject":"Re: Git Submodule Problem - Bug?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-11-29T10:25:41Z","receivedAt":"2011-11-29T10:25:41Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Fredrik Gustafsson wrote:\n> > [removing a submodule and adding another under the same name\n> > confuses git]\n> \n> This is something I did not thought about when writing that patch. The\n> reason that this fails is that the part when the first submodule is\n> removed is no longer complete (as intended). Before this patch\n>      git config --remove-section submodule.sub &&\n>      git rm .gitmodules &&\n>      rm -rf sub &&\n> Did remove all the data associated with the submodule. That's no longer\n> the case.\n\nSo maybe the right questions to ask would be: what's the *official*\nway of removing a submodule completely?  Do we support overwriting\nsubmodules in the way Manuel wanted to?  Why not? :-)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"180083","messageId":"20111129104105.GA10839@kolya","threadId":"29037","inReplyTo":"201111291125.41943.trast@student.ethz.ch","subject":"Re: Git Submodule Problem - Bug?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-11-29T10:41:05Z","receivedAt":"2011-11-29T10:41:05Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:\n> So maybe the right questions to ask would be: what's the *official*\n> way of removing a submodule completely?  Do we support overwriting\n> submodules in the way Manuel wanted to?  Why not? :-)\n\nI suggest that we add a command for that;\ngit submodule remove <submodule>\n\nThat should be pretty easy and straight forward to do. However I would\nlike to hear what Jens, Heiko and/or Junio has to say before starting to\nimplement it.\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\nE-post: iveqy@iveqy.com\nTel. nr.: 0733 60 82 74\n"},{"id":"180095","messageId":"4ED5196B.5030200@web.de","threadId":"29037","inReplyTo":"20111129104105.GA10839@kolya","subject":"Re: Git Submodule Problem - Bug?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-11-29T17:42:03Z","receivedAt":"2011-11-29T17:42:03Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:\n> On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:\n>> So maybe the right questions to ask would be: what's the *official*\n>> way of removing a submodule completely?  Do we support overwriting\n>> submodules in the way Manuel wanted to?  Why not? :-)\n> \n> I suggest that we add a command for that;\n> git submodule remove <submodule>\n\nHmm, to me it looks like the problem is in \"git submodule add\". It\ndoesn't check if the submodule repo it finds in .git/modules matches\nthe one the user wants to create. So we end up reviving the first\nsubmodule although the user wants to use a completely different repo.\n\nOne solution could be to only let \"git submodule update\" revive\nsubmodules from .git/modules and make \"git submodule add\" error out\nif it finds the git directory of a submodule with the same name in\n.git/modules. But currently there is no way to tell \"git submodule add\"\nto use a different submodule name (it always uses the path as a name),\nso we might have to add an option to do that and tell the user in the\nerror message how he can add a different submodule under the same\npath.\n\nAnother solution could be that \"git submodule add\" detects that a\nsubmodule with the name \"sub\" did exist and chooses a different name\n(say \"sub2\") for the the new one. Then the user wouldn't have to\ncope with the problem himself.\n"},{"id":"180096","messageId":"839E634E-76C0-40ED-8CCC-43E52F782079@gmail.com","threadId":"29037","inReplyTo":"4ED5196B.5030200@web.de","subject":"Re: Git Submodule Problem - Bug?","fromName":"Manuel Koller","fromEmail":"koller.manuel@gmail.com","sentAt":"2011-11-29T18:15:39Z","receivedAt":"2011-11-29T18:15:39Z","isPatch":false,"sender":{"key":"koller.manuel@gmail.com","avatar":null},"body":"Thanks for taking my problem seriously.\n\nOn 29.11.2011, at 18:42, Jens Lehmann wrote:\n\n> Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:\n>> On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:\n>>> So maybe the right questions to ask would be: what's the *official*\n>>> way of removing a submodule completely?  Do we support overwriting\n>>> submodules in the way Manuel wanted to?  Why not? :-)\n>> \n>> I suggest that we add a command for that;\n>> git submodule remove <submodule>\n> \n> Hmm, to me it looks like the problem is in \"git submodule add\". It\n> doesn't check if the submodule repo it finds in .git/modules matches\n> the one the user wants to create. So we end up reviving the first\n> submodule although the user wants to use a completely different repo.\n\nIn 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).\n\n> One solution could be to only let \"git submodule update\" revive\n> submodules from .git/modules and make \"git submodule add\" error out\n> if it finds the git directory of a submodule with the same name in\n> .git/modules. But currently there is no way to tell \"git submodule add\"\n> to use a different submodule name (it always uses the path as a name),\n> so we might have to add an option to do that and tell the user in the\n> error message how he can add a different submodule under the same\n> path.\n> \n> Another solution could be that \"git submodule add\" detects that a\n> submodule with the name \"sub\" did exist and chooses a different name\n> (say \"sub2\") for the the new one. Then the user wouldn't have to\n> cope with the problem himself.\n\nWhat 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. "},{"id":"180102","messageId":"7vobvuspir.fsf@alter.siamese.dyndns.org","threadId":"29037","inReplyTo":"839E634E-76C0-40ED-8CCC-43E52F782079@gmail.com","subject":"Re: Git Submodule Problem - Bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-29T19:21:48Z","receivedAt":"2011-11-29T19:21:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Manuel Koller <koller.manuel@gmail.com> writes:\n\n> In have wrote a workaround for the problem i posted that goes into this\n> direction. I just check whether the url has changed and remove the\n> submodule by hand if it did.\n\n... which might be wrong, depending on how you implement it, so be careful\n(see below).\n\n> ...\n> What is the purpose of having two different submodules in the same path?\n> Identifying the submodule by url however would probably make things\n> considerably faster...\n\nThere are three primary things involved when talking about a submodule in\na superproject. Its name, its path in the superproject hierarchy, and its\nURL (if it is foreign). The canonical example used when discussing the\ndesign of Git submodule support is to imagine your superproject that is\nabout a small router that has a kernel component as a submodule that lives\nin kernel/ hierarchy (your userland may live elsewhere in the tree, either\nas a submodule bound at src/ hierarchy or contained in the superproject\nitself and it does not make a difference).\n\nYou may had two major versions of your product. v1.0 line used to use BSD\nkernels, and v2.0 line with linux-2.6 kernels. Even though a checkout of\nany version of your superproject has a submodule bound at its kernel/\ndirectory, the logical identity of the submodule used in your v1.0 line of\nproduct and v2.0 line are different. You can differenciate them by giving\nthem different names, say 'kernel' and 'linux-kernel' [*1*]. When you\ncheckout the v1.0 tag, kernel/ directory should be populated by the\nsubmodule that house the BSD kernel. When you checkout the v2.0 tag, it\nshould house the Linux 2.6 kernel.\n\nNow, your v3.0 line will still use linux-2.6 (and now linux-3.0)\nkernel. Logically, the kernel project is the same thing. linux-3.0 is just\na continuation of linux-2.6 series and maintained in the *logically* same\nupstream repository. However, the repository location has recently changed\nand now lives in\n\n    http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n\neven though it used to be linux-2.6.git in the same hierarchy [*2*]. The\nname of the submodule ('linux-kernel') does not have to change, as the\nrepository in the new location has all the history for linux-2.6 kernel as\nwell. The URL mapping recorded in .gitmodules in-tree from the submodule\nname to the location however needs to change [*3*]. Ideally (I do not\nthink the current \"git submodule\" implementation does this), there should\nbe a more automated way to optionally allow switching the upstream URL of\nthe 'linux-kernel' subproject bound at kernel/ directory when you switch\nbetween commits in the v2.0 series and in the v3.0 series of the\nsuperproject [*3*], so that the user can say \"Yes, I know linux.git URL\ncontains everything needed from linux-2.6.git URL, so just update the\nsubmodule's upstream URL to linux.git one, and keep it like so; there is\nno need to use the older URL even when I check out v2.0 from the\nsuperproject\" or \"Notice when the URL recorded in .gitmodules for this\nproject changes when I check out a different version of the superproject,\nand use the old URL to update the submodule when I check out the old\nversion of the superproject\".\n\nEven though it is an ancient design discussion, this thread is worth a\nread before discussing anything about submodules:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47498\n\nnot because the ideas that were discussed but not implemented in the\ncurrent \"git submodule\" are all good things that should be added, but\nbecause the discussion shows what kind of considerations need to go into\nthe design.\n\n\n[Footnotes]\n\n*1* In the ideal world, you would have called it 'bsd' back in your v1.0\ndays with a foresight that someday you would switch to 'linux', but it is\nlikely you would not have been perfect.\n\n*2* You can still access it as linux-2.6.git because k.org is trying to be\nnice to its users, but that is besides the point.\n\n*3* It becomes relevant if you imagine a case where the old linux-2.6.git\nrepository at k.org were left frozen at the last version of the 2.6 series\nand the new history is only available in linux.git repository.\n"},{"id":"180120","messageId":"20111129220303.GA2812@sandbox-rc.fritz.box","threadId":"29037","inReplyTo":"4ED5196B.5030200@web.de","subject":"Re: Re: Git Submodule Problem - Bug?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-11-29T22:03:18Z","receivedAt":"2011-11-29T22:03:18Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Nov 29, 2011 at 06:42:03PM +0100, Jens Lehmann wrote:\n> Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:\n> > On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:\n> >> So maybe the right questions to ask would be: what's the *official*\n> >> way of removing a submodule completely?  Do we support overwriting\n> >> submodules in the way Manuel wanted to?  Why not? :-)\n> > \n> > I suggest that we add a command for that;\n> > git submodule remove <submodule>\n> \n> Hmm, to me it looks like the problem is in \"git submodule add\". It\n> doesn't check if the submodule repo it finds in .git/modules matches\n> the one the user wants to create. So we end up reviving the first\n> submodule although the user wants to use a completely different repo.\n> \n> One solution could be to only let \"git submodule update\" revive\n> submodules from .git/modules and make \"git submodule add\" error out\n> if it finds the git directory of a submodule with the same name in\n> .git/modules. But currently there is no way to tell \"git submodule add\"\n> to use a different submodule name (it always uses the path as a name),\n> so we might have to add an option to do that and tell the user in the\n> error message how he can add a different submodule under the same\n> path.\n\nI think this is the way to go. We teached submodule add to revive a\nlocal submodule. Further thinking about it this is probably not what the\nusers wants in most cases. For update its the right thing but for add we\nshould probably tell the user that there is already a local submodule in\nthe way and give him the option to take it or that he should remove it.\n\n> Another solution could be that \"git submodule add\" detects that a\n> submodule with the name \"sub\" did exist and chooses a different name\n> (say \"sub2\") for the the new one. Then the user wouldn't have to\n> cope with the problem himself.\n\nIn my opinion this is too much automatism. We could prompt for a new\nname to support the user but I do not think this mechanism should be\nautomatic.\n\nHow about this:\n\nThe user issues 'git submodule add foo' and we discover that there is\nalready a local clone under the name foo. Git then asks something like\nthis\n\n\tError when adding: There is already a local submodule under the\n\tname 'foo'.\n\n\tYou can either rename the submodule to be added to a different\n\tname or manually remove the local clone underneath\n\t.git/modules/foo. If you want to remove the local clone please\n\tquit now.\n\n\tWe strongly suggest that you give each submodule a unique name.\n\tNote: This name is independent from the path it is bound to.\n\n\tWhat do you want me to do ([r]ename it, [Q]uit) ?\n\nWhen the user chooses 'rename' git will prompt for a new name.\n\nIf we are going to support the remove use case with add we additionally\nneed some logic to deal with it during update (which is not supported\nyet AFAIK). But we probably need this support anyway since between\nremoval and adding a new submodule under the same can be a long time.\nIf users switch between such ancient history and the new history we\nwould have the same conflict.\n\nWe could of course just error out and tell the user that he has to give\nthe submodule an uniqe name. If the user does not do so leave it to him\nto deal with the situation manually.\n\nWhat do you think?\n\nCheers Heiko\n"},{"id":"180468","messageId":"CAPUobv1QnuAT76=yGDM-KKjoiXCzMt0jCda0LdYxAjN49qmAgA@mail.gmail.com","threadId":"29037","inReplyTo":"20111129220303.GA2812@sandbox-rc.fritz.box","subject":"Re: Re: Git Submodule Problem - Bug?","fromName":"Manuel Koller","fromEmail":"koller.manuel@gmail.com","sentAt":"2011-12-07T08:21:50Z","receivedAt":"2011-12-07T08:21:50Z","isPatch":false,"sender":{"key":"koller.manuel@gmail.com","avatar":null},"body":"> How about this:\n>\n> The user issues 'git submodule add foo' and we discover that there is\n> already a local clone under the name foo. Git then asks something like\n> this\n>\n>        Error when adding: There is already a local submodule under the\n>        name 'foo'.\n>\n>        You can either rename the submodule to be added to a different\n>        name or manually remove the local clone underneath\n>        .git/modules/foo. If you want to remove the local clone please\n>        quit now.\n>\n>        We strongly suggest that you give each submodule a unique name.\n>        Note: This name is independent from the path it is bound to.\n>\n>        What do you want me to do ([r]ename it, [Q]uit) ?\n>\n> When the user chooses 'rename' git will prompt for a new name.\n>\n> If we are going to support the remove use case with add we additionally\n> need some logic to deal with it during update (which is not supported\n> yet AFAIK). But we probably need this support anyway since between\n> removal and adding a new submodule under the same can be a long time.\n> If users switch between such ancient history and the new history we\n> would have the same conflict.\n>\n> We could of course just error out and tell the user that he has to give\n> the submodule an uniqe name. If the user does not do so leave it to him\n> to deal with the situation manually.\n>\n> What do you think?\n>\n> Cheers Heiko\n\nPrompt to choose another name would be fine I guess - but it solves\nthe problem only if the submodule has been initialized already. There\ncould be a submodule of the same name in another branch, which I\nhaven't checked out yet, for example. The user would have to be forced\nchoose a unique name for every submodule.\n\nAnyway, it seems impossible to handle a name clash automatically,\nsince there are good reasons to have different urls for the same\nsubmodule. Having read the thread linked by Junio, the only way out\nseems to be a kind of url rewrite scheme and using the url as name.\nDoesn't it solve all the problems?\n\n- the url is more or less unique (there are problems now if we have to\ndifferent submodules at the same path, which is much more likely to\nhappen than a different repository at the same url some time in the\nfuture)\n- after a change of the submodule's url, we can still check out old\ncommits in a comfortable way\n- we could have the same submodule at different paths, but downloaded only once\n- the user is not forced to do anything, but the .gitmodule config can\nstill be overruled if necessary\n"},{"id":"180529","messageId":"4EDFE126.2060504@web.de","threadId":"29037","inReplyTo":"CAPUobv1QnuAT76=yGDM-KKjoiXCzMt0jCda0LdYxAjN49qmAgA@mail.gmail.com","subject":"Re: Git Submodule Problem - Bug?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-07T21:56:54Z","receivedAt":"2011-12-07T21:56:54Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 07.12.2011 09:21, schrieb Manuel Koller:\n>> How about this:\n>>\n>> The user issues 'git submodule add foo' and we discover that there is\n>> already a local clone under the name foo. Git then asks something like\n>> this\n>>\n>>        Error when adding: There is already a local submodule under the\n>>        name 'foo'.\n>>\n>>        You can either rename the submodule to be added to a different\n>>        name or manually remove the local clone underneath\n>>        .git/modules/foo. If you want to remove the local clone please\n>>        quit now.\n>>\n>>        We strongly suggest that you give each submodule a unique name.\n>>        Note: This name is independent from the path it is bound to.\n>>\n>>        What do you want me to do ([r]ename it, [Q]uit) ?\n>>\n>> When the user chooses 'rename' git will prompt for a new name.\n>>\n>> If we are going to support the remove use case with add we additionally\n>> need some logic to deal with it during update (which is not supported\n>> yet AFAIK). But we probably need this support anyway since between\n>> removal and adding a new submodule under the same can be a long time.\n>> If users switch between such ancient history and the new history we\n>> would have the same conflict.\n>>is_submodule_modified()\n>> We could of course just error out and tell the user that he has to give\n>> the submodule an uniqe name. If the user does not do so leave it to him\n>> to deal with the situation manually.\n>>\n>> What do you think?\n>>\n>> Cheers Heiko\n> \n> Prompt to choose another name would be fine I guess - but it solves\n> the problem only if the submodule has been initialized already. There\n> could be a submodule of the same name in another branch, which I\n> haven't checked out yet, for example. The user would have to be forced\n> choose a unique name for every submodule.\n\nWhich seems pretty much impossible in a distributed system ...\n\n> Anyway, it seems impossible to handle a name clash automatically,\n> since there are good reasons to have different urls for the same\n> submodule.> Having read the thread linked by Junio, the only way out\n> seems to be a kind of url rewrite scheme and using the url as name.\n> Doesn't it solve all the problems?\n> \n> - the url is more or less unique (there are problems now if we have to\n> different submodules at the same path, which is much more likely to\n> happen than a different repository at the same url some time in the\n> future)\n> - after a change of the submodule's url, we can still check out old\n> commits in a comfortable way\n> - we could have the same submodule at different paths, but downloaded only once\n> - the user is not forced to do anything, but the .gitmodule config can\n> still be overruled if necessary\n\nHmm, using the URL has the downside that when one URL is just a fork of\nthe other we might have most of the repo duplicated in the .git/modules\ndirectory ... but if it solves the problem of having a totally different\nsubmodule cloned into the same path it might be worth it.\n"}]}