Re: Feature Request: Branch-Aware Submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> +cc Jacob and Lars who work with submodules as well.
>
> On Thu, Aug 25, 2016 at 2:00 AM, Hedges  Alexander
> <ahedges@xxxxxxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]