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

[Steve Borho]

On Sun, Mar 6, 2011 at 11:41 AM, Steve Borho <steve at borho.org> wrote:
> 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

FWIW: I'd like to see two other fixes on stable before a 1.8.1
release.  The setup.py version number problem and the issue with x64
Mercurial finding x86 merge tools in the Windows registry.

-- 
Steve Borho