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

Matt Mackall mpm at selenic.com
Mon Mar 7 15:49:05 CST 2011


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list