From: Stefan Beller <sbeller@google.com>
Date: Thu, 25 Aug 2016 20:55:59 GMT
Subject: Re: Feature Request: Branch-Aware Submodules
Message-ID: <CAGZ79ka60e2Y87k6oKtTN9e0ZexHx2GfJ7yfhvyQon_VgbUgNA@mail.gmail.com>
In-Reply-To: <xmqqlgzklgiy.fsf@gitster.mtv.corp.google.com>

On Thu, Aug 25, 2016 at 1:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> +cc Jacob and Lars who work with submodules as well.
>>
>> On Thu, Aug 25, 2016 at 2:00 AM, Hedges  Alexander
>> <ahedges@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.