push: introduce a discovery step for obsmarker The discovery step is still not doing anything smart. But this will allow extension to wrap it.

push: move the list of obsmarker to push into the push operation The list is now carried in the push operation, this will let extensions override it.

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)

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.

merge-tools: make premerge valid values extensible We want to introduce a version leaving merge3 style markers.

mergetools: add a test for premerge --keep It works! No surprise.

test-merge-tools: introduce a "revision 4" that merges with conflict We need conflicts to test the premerge=keep configuration.

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.

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.

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.