Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 13:22:44 -0700] rev 22038
rebase: do not retract phase boundary by hand
We rely on the internal mechanism to commit the changeset in the right phase.
This similar to what the mq extension is doing.
This is an important change as we plan to includes phase movement within the
transaction. Avoiding phase movement from high-level code will avoid the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is code using a different transaction for changeset creation
and phase adjustment.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 21:16:24 -0700] rev 22037
config: fix restoreconfig of non existing config
When the section, but no value existed, the `del` call raised a key error.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 31 Jul 2014 13:51:17 -0700] rev 22036
push: use stepsdone for obsmarkers push
We do not have infrastructure to include obsolescence markers in the bundle2
push from core. But extensions may so we make sure it would not be sent twice.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Jul 2014 19:32:20 +0200] rev 22035
push: introduce a discovery step for obsmarker
The discovery step is still not doing anything smart. But this will allow
extension to wrap it.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Jul 2014 19:17:09 +0200] rev 22034
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.
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
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.