Re: Amending merge commits?

From: Philip Oakley <philipoakley@iee.org>
Date: Jul 29, 2014, 19:29 UTC
Message-ID: <DFE66A48CBC646E795B3B4A0903AB19E@PhilipOakley>
In-Reply-To: <CAK3OfOhFzbUA7gZbox84W=VC+0aSuiNc-XRP_MTyYy1UeFFzZQ@mail.gmail.com>

From: "Nico Williams" <nico@cryptonector.com>

Show 24 quoted lines

> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <osv@javad.com> wrote:
>> Nico Williams <nico@cryptonector.com> writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in 
>>> simplifying
>>> conflict resolution, b) making it easy to identify 
>>> as-yet-unintegrated
>>> local commits, c) making it easy to contribute local commits.
>>
>> But 'pull --rebase=preserve' does rebase local commits onto the
>> upstream, and result is exactly the same as 'pull --rebase=true', 
>> unless
>> you have some of your own merges to be rebased. That's where the
>> difference between these two options appears. It's --rebase=false 
>> that
>> performs merges rather than rebase.
>
> Local merge commits mean that you either didn't rebase to keep all
> your local commits on top of the upstream, or that you have multiple
> upstreams (the example exception I gave).
>
> Conversely, if you always rebase your local commits on top of the
> upstream then you won't have merge commits to worry about.
>

Whilst it may not be "the Git Way", I'd expect that in many less well informed companies, the need to keep merge commits fom other lines of development would be quite a common (political ) technique where some preparatory branch needs to be merged in before one's feature can be completed (similar to all those cases on the list when folk say 'builds on top of xy's commit deadbeaf)

Philip