From: Junio C Hamano Date: Thu, 25 Aug 2016 21:25:32 GMT Subject: Re: Feature Request: Branch-Aware Submodules Message-ID: In-Reply-To: Stefan Beller writes: >>> So you roughly do >>> >>> git checkout -b new-topic >>> # change the submodule to point at the latest upstream version: >>> git submodule update --remote >>> git commit -a -m "update submodule" >>> git checkout master >>> git merge new-topic >>> # here seems to be your point of critic? >>> # now the submodule pointer would still point to the latest >>> upstream version? >> >> Isn't subject to the usual 3-way merge when the >> last step (i.e. a merge of new-topic branch into master in the >> superproject) is made? If 'master' hasn't changed >> since 'new-topic' forked from it, because 'new-topic' updated the >> commit bound at , doesn't "git merge new-topic" just >> take that change as the normal "One side updated, the other did not >> touch; take the update" merge? > > Yes. I was unclear here. > By "latest upstream version" I meant the version you pulled in in the new-topic > branch via the "submodule update --remote" and that is preserved as is. I do not think you were unclear at all. What else is desired? "git merge new-topic" leaves a result that is not a merge of the changes made on that new-topic branch, by leaving a stale that was in 'master' as-is? After all, the new-topic branch committed that "update submodule", showing its desire that the latest-from-upstream commit it just obtained must be at from then on in the top-level project. If that change is not propagated (or at least "taken into account") when merging it to 'master', the result is not a proper "merge". If new-topic didn't want the updated commit from the submodule, it shouldn't have recorded that in its commit in the first place.