On Thu, Aug 25, 2016 at 1:50 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> +cc Jacob and Lars who work with submodules as well. >> >> On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander >> <ahed...@student.ethz.ch> wrote: >>> >>> Right now updating a submodule in a topic branch and merging it into master >>> will not change the submodule index in master leading to at least two commit >>> for the same change (one in any active branch). This happened to me quite a >>> few >>> times. To a newcomer this behavior is confusing and it leads to unnecessary >>> commits. >> >> So you roughly do >> >> git checkout -b new-topic >> # change the submodule to point at the latest upstream version: >> git submodule update --remote <submodule-path> >> 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 <submodule-path> 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 <submodule-path> > since 'new-topic' forked from it, because 'new-topic' updated the > commit bound at <submodule-path>, 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
