Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Jul 2014 19:31:49 +0200] rev 22033
push: explicitly encode a list of obsmarkers to push
Sending obsmarkers through pushkey requires extra encoding (since pushkey can't
take binary content) and slicing (since we can hit http header limit). As we
send all obsolescences markers that exists in the repo for each push, we used to
just look at the content of the "obsolete" pushkey namespace (already encoded
and sliced) and send its
content.
However, future changeset will make it possible to push only parts of the
obsmarkers. To prepare this we now explicitly encode a list of markers. The list
of markers is still "all of them" but future changeset will takes care
of that.
The new code uses a "_protected" method but that seems reasonable to keep it
private as this is the is the only external user of it and this whole pushing
obsmarker through pushkey things in fairly hacky already)
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.
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.
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.
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.
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