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

[Steve Borho]

On Sun, Mar 6, 2011 at 12:52 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Sun, 2011-03-06 at 12:28 -0600, Steve Borho wrote:
>> 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.
>
> I can't reproduce the version number problem here and I have no idea
> about the second one.

On x64 Windows systems, registry keys created by 32bit applications
are rooted under a special registry node labeled Wow6432Node, so when
our newly native 64bit Mercurial tries to find merge tools it will not
find any that were installed as 32bit apps (which most of them still
are).

Adrian and I have been discussing a resolution on IRC and in this bug report

https://bitbucket.org/tortoisehg/thg/issue/209

-- 
Steve Borho