git pull with submodule

git pull with submodule

[Sascha Cunz]

I noticed the following behaviour when pulling a repository that has a 
submodule.

I have a standalone checkout of my subproject, which I regulary sync it with 
its upstream and push the result to github. Then I go to my project where the 
github repository is setup to be a subproject, 'cd' into the subproject and do 
'git pull' there. After that, I commit the subproject blob into the 
superproject.

Now i switch OS and/or workstation and do a 'git pull' ( in root directory of 
superproject ). Git then
	-> fetches new objects of superproject
	-> fetches new objects of subproject
	-> checks out the subproject to the SHA1 currently recorded in
      the subproject blob. (Am i right on this one?)
	-> merges superproject with it's upstream

After that, i have to cd into the subproject and 'git pull' there again, 
because it just fetched the objects but did no merge nor checkout.

Is this intentional behaviour or am i doing something wrong / have wrong 
expectations in that "after seeing it recurring into the subproject, i expect 
i don't need to do further steps in order to have it up to date"?

SaCu

PS I'm using a mix of git Versions 1.7.{6,8,10}

Re: git pull with submodule

[Jens Lehmann]

Am 23.06.2012 15:53, schrieb Sascha Cunz:
> I noticed the following behaviour when pulling a repository that has a 
> submodule.
> 
> I have a standalone checkout of my subproject, which I regulary sync it with 
> its upstream and push the result to github. Then I go to my project where the 
> github repository is setup to be a subproject, 'cd' into the subproject and do 
> 'git pull' there. After that, I commit the subproject blob into the 
> superproject.
> 
> Now i switch OS and/or workstation and do a 'git pull' ( in root directory of 
> superproject ). Git then
> 	-> fetches new objects of superproject
> 	-> fetches new objects of subproject
> 	-> checks out the subproject to the SHA1 currently recorded in
>       the subproject blob. (Am i right on this one?)

No, you have to issue a "git submodule update" to check out the submodule
according to the commit that is registered in the superproject. Only the
SHA1 currently recorded in the superproject will be updated when the merge
succeeds, the submodules work tree and HEAD stays untouched.

> 	-> merges superproject with it's upstream
> 
> After that, i have to cd into the subproject and 'git pull' there again, 
> because it just fetched the objects but did no merge nor checkout.

Hmm, the merge of the submodule commits in the superproject should have
already been done by your pull there (as I understand your use case you
only move the submodules commits forward, so there are no merge conflicts
to be expected). Just doing a "git submodule update" in the superproject
after the pull should do the trick.

> Is this intentional behaviour or am i doing something wrong / have wrong 
> expectations in that "after seeing it recurring into the subproject, i expect 
> i don't need to do further steps in order to have it up to date"?

This is the way things currently work. There is ongoing work to get rid
of the need to run "git submodule update" when the commit recorded in
the superproject changes due to a checkout, pull or whatever, but we're
not there yet.