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

Adrian Buehlmann adrian at cadifra.com
Mon Mar 7 16:39:05 CST 2011


On 2011-03-07 22:49, Matt Mackall wrote:
> On Sun, 2011-03-06 at 17:03 -0600, Steve Borho wrote:
>> 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
> 
> Lemme know if you have an ETA on this. I'd like to release 1.8.1 in the
> next couple days so we don't get too many adopters of the version with
> fast-forward merges.

I wanted to work on that bug, but -- from my POV -- please don't wait
with releasing 1.8.1.

ETA at the moment is probably days: but it might be even a week. Lame
unprofessional volunteers and all, you know.



More information about the Mercurial-devel mailing list