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

Matt Mackall mpm at selenic.com
Sun Mar 6 12:52:02 CST 2011


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list