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

[Kevin Bullock]

On Mar 6, 2011, at 9:26 AM, Mads Kiilerich wrote:

> FUJIWARA Katsunori wrote, On 03/06/2011 11:24 AM:
>> The behavior of Mercurial on merge between named branches is changed
>> to 'fast-forward' style since 1.8 by 9e7e24052745.
> 
> Yes. I proposed a bugfix in http://selenic.com/pipermail/mercurial-devel/2010-December/026695.html and asked some questions. Matt pushed it for 1.8 without further comments.
> 
> The way I tend to see it a merge merges two diverging branches of development. Merging with an ancestor is by definition not a merge. The data model and most algorithms allows merging with an ancestor, but it seems to me like we have an invariant that says that merge changesets must merge diverged branches of development.
> 
> One place where merging with an ancestor causes trouble is when convert cleans up the converted changesets - see Issue2538.
> 
> I can however see how the old behavior can be convenient, mostly because the current graph visualizations doesn't visualize "changesets on same branch are related" very clearly. I think that is the main problem, not that we do fast forward merges across named branches. See Issue2678.

With the 1.8 (fast-forward) behavior, it becomes impossible to distinguish between `hg branch -f foo`, meaning we're explicitly _replacing_ the 'foo' branch, and `hg up foo; hg merge bar`, meaning that the latest code on 'bar' should be taken as the latest code on 'foo' as well:

foo  --o---o   *
            \ /
bar  ----o---o

vs.

foo  --o---o---*
            \ /
bar  ----o---o

It's not a merge in the sense of having to run the merge algorithm, but the merge changeset having both parents nonetheless encodes useful meaning about what happened to the code.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock