[PATCH 0 of 1] merge: add --no-fast-forward to suppress fast-forward merge

[Steve Borho]

On Sun, Mar 6, 2011 at 10:57 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Sun, 2011-03-06 at 19:24 +0900, FUJIWARA Katsunori wrote:
>> The behavior of Mercurial on merge between named branches is changed
>> to 'fast-forward' style since 1.8 by 9e7e24052745.
>>
>> There is quite a few people who requires 'old'(= not fast-forward)
>> style merge, but there is no way to choose 'old' style on merge.
>
> This is the first I've heard that. Why do they require it?
>
>> So, I tried to implement experimental patch to add '--no-fast-forward'
>> option.
>
> I'd rather not do that. Then people will have to know what a 'fast
> forward' merge is. And invariably, people won't know they've done the
> wrong type of merge until it's already committed. So we're either going
> to do this type of merge or we aren't.
>
> Upsides:
>
> - p1 being in ::p2 may confuse some algorithms
> - history looks a bit more linear
>
> Downsides:
>
> - it gives merges that aren't merges by the normal definition and aren't
> skipped by log -M or matched by the merge() revset
> - named branches are more likely to become disconnected in history
>
>
> I may have made an earlier claim that fast-forward might avoid some bad
> ancestor selection in some future merges, but I just took a closer look
> at the ancestor algorithm and it's correctly no affected at all by using
> or not using fast-forward.
>
>
> I'm leaning towards reverting this change and releasing an early 1.8.1,
> unless people have strong opinions on why we want to keep it.

I'm +1 for a backout.

https://bitbucket.org/tortoisehg/thg/issue/215/empty-diff-on-merge-revision

-- 
Steve Borho