Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 05 Aug 2014 14:58:45 -0700] rev 22028
merge: add an internal:merge3 tool
This variant gives access to a feature already present in ``internal:merge``:
displaying merge base content.
In the basic merge (calling ``hg merge``) case, including more context to the
merge markers is an interesting addition.
But this extra information is the only viable option in case conflict from
grafting (, rebase, etc…).
When grafting ``source`` on ``destination``, the parent of ``source`` is
used as the ``base``. When all three changesets add content in the same
location, the marker for ``source`` will contains both ``base`` and ``source``
content. Without the content of base exposed, there is no way for the user
to discriminate content coming from ``base`` and content commit from ``source``.
Practical example (all addition are in the same place):
* ``destination`` adds ``Dest-Content``
* ``base`` adds ``Base-Content``
* ``source`` adds ``Src-Content``
Grafting ``source`` on ``destination`` will produce the following conflict:
<<<<<<< destination
Dest-Content
=======
Base-Content
Src-Content
>>>>>>> source
This that case there is no way to distinct ``base`` from ``source``. As a result
content from ``base`` are likely to slip in the resolution result.
However, adding the base make the situation very clear:
<<<<<<< destination
Dest-Content
||||||| base
Base-Content
======= base
Base-Content
Src-Content
>>>>>>> source
Once the base is added, the addition from the grafted changeset is made clear.
User can compare the content from ``base`` and ``source`` to make an enlightened
decision during merge resolution.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 15:09:54 -0700] rev 22027
internal:merge: update documentation
Highlight the fact there are two regions in the markers and what their contents
are. This prepares for the arrival of merge3.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 15:17:38 -0700] rev 22026
filemerge: allow the formatting of three labels instead of two
When a third label is provided (to included the base content) it is properly
processed as the two others. Nothing changes if only two labels are provided.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 15:12:22 -0700] rev 22025
filemerge: drop extra white space
There should be no white space around the brace.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 15:10:50 -0700] rev 22024
simplemerge: support three labels when merging
If a third label is provided it will be used for the "base" content:
<<<<<<< local
content
from
local
||||||| base
former
common
=======
other
conflicting
>>>>>>> other
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 14:56:25 -0700] rev 22023
simplemerge: burn "minimal" feature to the ground
Matt Mackall said:
The goal of simplemerge should have always been to be a drop-in
replacement for RCS merge. Please nuke this minimization thing entirely.
This whole things is now dead.