[PATCH 0 of 1] merge: add --no-fast-forward to suppress fast-forward merge
steve at borho.org
Sun Mar 6 12:28:10 CST 2011
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'
>> 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.
>> - p1 being in ::p2 may confuse some algorithms
>> - history looks a bit more linear
>> - 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.
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.
More information about the Mercurial-devel