[PATCH 5 of 6] simplemerge: add ``base`` mode to ``mergemarkersscope`` config

[Matt Mackall]

On Fri, 2014-07-25 at 15:58 +0200, Pierre-Yves David wrote:
> 
> On 07/19/2014 05:36 AM, Matt Mackall wrote:
> > On Tue, 2014-06-10 at 13:50 -0700, pierre-yves.david at ens-lyon.org wrote:
> >> # HG changeset patch
> >> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> >> # Date 1348740176 -7200
> >> #      Thu Sep 27 12:02:56 2012 +0200
> >> # Node ID fe435e1caaab581f4c67ea44c7075f38e7102575
> >> # Parent  9282f318c729d672c05fd3364b8d2fce80ecac3b
> >> simplemerge: add ``base`` mode to ``mergemarkersscope`` config
> >>
> >> This options give access to a feature already present in ``internal:merge``:
> >> displaying merge base base content.
> > ...
> >> +  $ cat a
> >> +  Small Mathematical Series.
> >> +  <<<<<<< local
> >> +  1
> >> +  2
> >> +  3
> >> +  6
> >> +  8
> >> +  ======= base
> >> +  One
> >> +  Two
> >> +  Three
> >> +  Four
> >> +  Five
> >> +  =======
> >> +  1
> >> +  2
> >> +  3
> >> +  4
> >> +  5
> >> +  >>>>>>> other
> >
> > Except it's supposed to look like this:
> >
> > $ merge -p -A local base other
> > <<<<<<< local
> > 1
> > 2
> > 3
> > 6
> > 8
> > ||||||| base
> > One
> > Two
> > Three
> > Four
> > Five
> > =======
> > 1
> > 2
> > 3
> > 4
> > 5
> >>>>>>>> other
> > merge: warning: conflicts during merge
> >
> > This would be better as something like internal:merge3way.
> >
> > I also can't agree to accepting it as any sort of default behavior like
> > in patch 6: this is functionality you literally can't get in CVS or SVN
> > without patching the code and needs you to use the fairly obscure
> > setting "merge.conflictstyle=diff3" in Git... so you're going to have a
> > hard time convincing me it's an essential behavior change 58 years after
> > RCS was released and 9 years after Git and Hg.
> >
> > https://lists.nongnu.org/archive/html/info-cvs/2002-06/msg00254.html
> > https://stackoverflow.com/questions/21740250/configuring-subversion-client-to-use-3-way-conflict-markers
> 
> But none of CVS, SVN or merge(1) had to deal with magic merge from a 
> graft (or a rebase, or and histedit or an evolve or …).

Actually people did grafts in CVS all the time, it was just less
automated. There's a reason that the merge(1) manpage doesn't tell you
what file1/2/3 represent.

> In this case, the two way markers is -broken- and produce bad result 
> that result in user doing bad merge resolution.
> 
> See details here: 
> http://www.selenic.com/pipermail/mercurial-devel/2014-June/059582.html

There's technically nothing specific to graft-like merging there. It's
just a bit more common to have deleted/replaced context in a graft
because it will reverse one or more links in the merge path:

o-a-b-G
   \  |   <- this graft is semantically the same as..
    c-d

o-c-ā-b-M  <- this merge where ā undoes the a->c changes
   \   /
    d-'

But as it's perfectly normal to have deletions or replacements in normal
changesets, this situation is nothing new. Again: 32 years of
RCS/CVS/SVN precedence, 9 years of Git precedence.

> As the usage of such merge become more and more frequent in DVCS, we 
> -need- a proper fixes for this bug.

Yes, and that fix is "for the love of god, stop using those nasty merge
markers from the 70s". A fix I made literally on day one of Mercurial
development.

But for people who _insist_ on being retro, I'm all for adding an option
to turn on 3-way markers. But not on by default: some people have been
happy for years with their nasty markers and I don't want to confuse
them in the middle of a merge.

-- 
Mathematics is the supreme nostalgia of our time.