{"thread":{"id":"30887","subject":"git pull with submodule","startedAt":"2012-06-23T13:53:26Z","lastAt":"2012-06-24T18:24:34Z","messageCount":2,"participants":["Sascha Cunz","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194161","messageId":"1564611.U3XyAbWYKV@toshi","threadId":"30887","inReplyTo":null,"subject":"git pull with submodule","fromName":"Sascha Cunz","fromEmail":"sascha-ml@babbelbox.org","sentAt":"2012-06-23T13:53:26Z","receivedAt":"2012-06-23T13:53:26Z","isPatch":false,"sender":{"key":"sascha-ml@babbelbox.org","avatar":null},"body":"I noticed the following behaviour when pulling a repository that has a \nsubmodule.\n\nI have a standalone checkout of my subproject, which I regulary sync it with \nits upstream and push the result to github. Then I go to my project where the \ngithub repository is setup to be a subproject, 'cd' into the subproject and do \n'git pull' there. After that, I commit the subproject blob into the \nsuperproject.\n\nNow i switch OS and/or workstation and do a 'git pull' ( in root directory of \nsuperproject ). Git then\n\t-> fetches new objects of superproject\n\t-> fetches new objects of subproject\n\t-> checks out the subproject to the SHA1 currently recorded in\n      the subproject blob. (Am i right on this one?)\n\t-> merges superproject with it's upstream\n\nAfter that, i have to cd into the subproject and 'git pull' there again, \nbecause it just fetched the objects but did no merge nor checkout.\n\nIs this intentional behaviour or am i doing something wrong / have wrong \nexpectations in that \"after seeing it recurring into the subproject, i expect \ni don't need to do further steps in order to have it up to date\"?\n\nSaCu\n\nPS I'm using a mix of git Versions 1.7.{6,8,10}\n"},{"id":"194170","messageId":"4FE75B62.9020107@web.de","threadId":"30887","inReplyTo":"1564611.U3XyAbWYKV@toshi","subject":"Re: git pull with submodule","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-24T18:24:34Z","receivedAt":"2012-06-24T18:24:34Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 23.06.2012 15:53, schrieb Sascha Cunz:\n> I noticed the following behaviour when pulling a repository that has a \n> submodule.\n> \n> I have a standalone checkout of my subproject, which I regulary sync it with \n> its upstream and push the result to github. Then I go to my project where the \n> github repository is setup to be a subproject, 'cd' into the subproject and do \n> 'git pull' there. After that, I commit the subproject blob into the \n> superproject.\n> \n> Now i switch OS and/or workstation and do a 'git pull' ( in root directory of \n> superproject ). Git then\n> \t-> fetches new objects of superproject\n> \t-> fetches new objects of subproject\n> \t-> checks out the subproject to the SHA1 currently recorded in\n>       the subproject blob. (Am i right on this one?)\n\nNo, you have to issue a \"git submodule update\" to check out the submodule\naccording to the commit that is registered in the superproject. Only the\nSHA1 currently recorded in the superproject will be updated when the merge\nsucceeds, the submodules work tree and HEAD stays untouched.\n\n> \t-> merges superproject with it's upstream\n> \n> After that, i have to cd into the subproject and 'git pull' there again, \n> because it just fetched the objects but did no merge nor checkout.\n\nHmm, the merge of the submodule commits in the superproject should have\nalready been done by your pull there (as I understand your use case you\nonly move the submodules commits forward, so there are no merge conflicts\nto be expected). Just doing a \"git submodule update\" in the superproject\nafter the pull should do the trick.\n\n> Is this intentional behaviour or am i doing something wrong / have wrong \n> expectations in that \"after seeing it recurring into the subproject, i expect \n> i don't need to do further steps in order to have it up to date\"?\n\nThis is the way things currently work. There is ongoing work to get rid\nof the need to run \"git submodule update\" when the commit recorded in\nthe superproject changes due to a checkout, pull or whatever, but we're\nnot there yet.\n"}]}