Re: Amending merge commits?

[Nico Williams <nico@cryptonector.com>]

On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Nico Williams" <nico@cryptonector.com>
>> That workflow works just fine with git.
>
> I'm not saying that it isn't a good technique and can work well. Rather I'm
> saying we should be tolerant of the rules and techniques of others who do
> [...]

Sure.  I was just giving advice as to how to avoid any problems at
pull time w.r.t. local merge commits.

Better merge commit handling at pull time might be great (I'd not
know; I avoid local merge commits!), but I would still strongly
recommend keeping all local commits on top because otherwise you lose
local history.  Even if you use -m to set a better commit message, you
might prefer to have kept the original N local -now rebased- commits
around so you can tell what each discrete change was, even if you'll
eventually squash them (you might not squash them all into one).

>>  It worked really well at Sun
>> (with thousands of engineers working on Solaris alone).  And it should
>> work well for anyone who doesn't have two or more forked upstreams to
>> follow.
>
> I'm just cautious of an accidental one size fits all approach, so the
> ability to rebase lines of development which contain merge commits should be
> possible (with an appropriate and documented option) without hidden traps.

Thus far the only case I've seen where this approach doesn't work _at
all_ is the case where you have multiple forked upstreams.  The only
other case where it doesn't work is a social problem: rebase allergy.
For the repos I maintain I insist on contributed commits applying as
fast forward merges, or I'll rebase them myself if need be.

Nico
--