Mon, 04 Aug 2014 16:32:41 -0700 merge-tools: add a `premerge=keep-merge3` config option
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 04 Aug 2014 16:32:41 -0700] rev 22032
merge-tools: add a `premerge=keep-merge3` config option This value leaves premerge markers that includes the merge base too. This is a the same as what `internal:merge3` would do.
Mon, 04 Aug 2014 16:58:39 -0700 merge-tools: make premerge valid values extensible
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 04 Aug 2014 16:58:39 -0700] rev 22031
merge-tools: make premerge valid values extensible We want to introduce a version leaving merge3 style markers.
Mon, 04 Aug 2014 16:50:15 -0700 mergetools: add a test for premerge --keep
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 04 Aug 2014 16:50:15 -0700] rev 22030
mergetools: add a test for premerge --keep It works! No surprise.
Mon, 04 Aug 2014 16:39:47 -0700 test-merge-tools: introduce a "revision 4" that merges with conflict
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 04 Aug 2014 16:39:47 -0700] rev 22029
test-merge-tools: introduce a "revision 4" that merges with conflict We need conflicts to test the premerge=keep configuration.
Tue, 05 Aug 2014 14:58:45 -0700 merge: add an internal:merge3 tool
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.
Tue, 05 Aug 2014 15:09:54 -0700 internal:merge: update documentation
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip