Sean Farley <sean.michael.farley@gmail.com> [Tue, 17 Jun 2014 20:26:51 -0700] rev 22055
basectx: add missing, merge, and branch args to dirty method
This fixes a discrepency for basectx and classes that inherit from it. Now
callers can pass these arguments to any context without an exception being
raised.
Sean Farley <sean.michael.farley@gmail.com> [Fri, 25 Jul 2014 20:11:47 -0500] rev 22054
basefilectx: move isexec and islink from memfilectx
This will be used in the future for creating memctx objects from other
store-type objects, such as a patch store or even another context.
Matt Mackall <mpm@selenic.com> [Wed, 06 Aug 2014 12:16:58 -0500] rev 22053
tests: fix pyflakes test whitespace breakage
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 06 Aug 2014 00:54:58 -0700] rev 22052
pushkey: wrap pushkey phase movement in a transaction
Phases are not yet inside the transaction, but we need to prepare for it. So we
wrap the phase movement inside a transaction.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 06 Aug 2014 00:54:15 -0700] rev 22051
push: wrap local phase movement in a transaction
Phases are not yet inside the transaction, but we need to prepare for it. So we
wrap the phase movement inside a transaction.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 06 Aug 2014 00:50:53 -0700] rev 22050
phase: wrap `hg phases` phase movement in a transaction
Phases are not yet inside the transaction, but we need to prepare for it. So we
wrap the phase movement inside a transaction.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 06 Aug 2014 00:50:07 -0700] rev 22049
mq: wrap qimport phase movement in a transaction
Phases are not yet inside the transaction, but we need to prepare for it. So we
wrap the phase movement inside a transaction.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 06 Aug 2014 00:48:51 -0700] rev 22048
mq: wrap qfinish phase movement in a transaction
Phases are not yet inside the transaction, but we need to prepare for it. So we
wrap the phase movement inside a transaction.
Matt Mackall <mpm@selenic.com> [Wed, 06 Aug 2014 11:53:08 -0500] rev 22047
tests: change some #ifs to #requires
Matt Mackall <mpm@selenic.com> [Wed, 06 Aug 2014 11:43:59 -0500] rev 22046
tests: replace exit 80 with #require
Matt Mackall <mpm@selenic.com> [Wed, 06 Aug 2014 10:34:54 -0500] rev 22045
run-tests: add #require to abort full test
This allows nuking a bunch of ugly hghave || exit 80 lines.
Augie Fackler <raf@durin42.com> [Tue, 05 Aug 2014 21:17:11 -0400] rev 22044
run-tests: add support for xunit test reports
The Jenkins CI system understands xunit reports natively, so this will
be helpful for anyone that wants to use Jenkins for testing hg or
extensions that use run-tests.py for their testing.
Matt Mackall <mpm@selenic.com> [Wed, 06 Aug 2014 02:45:55 -0500] rev 22043
contrib: add check-commit hook script to sanity-check commits
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 13:51:13 -0700] rev 22042
shelve: use `targetphase` while unbundling
This removes the last manual phase movement in shelve.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 13:49:38 -0700] rev 22041
changegroup: add a `targetphase` argument to `addchangegroup`
This argument controls the phase used for the added changesets. This can be
useful to unbundle in "secret" phase as required by shelve.
This change aims at helping high-level code get rid of manual phase
movement. An important milestone for having phases part of the transaction.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 14:37:45 -0700] rev 22040
shelve: do not retract phase boundary by hand
We rely on the internal mechanism to commit the changeset in the right state.
This is similar to what the mq extension is doing.
This is an important change as we plan to move phase movement with the
transaction. Avoiding phase movement from high level code will avoid them 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 to use a different transaction for changesets creation and
phase adjustment.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 05 Aug 2014 18:53:05 -0700] rev 22039
commit: update the --secret code to use backupconfig and restoreconfig
Those dedicated methods also preserve all associated data (eg:
sources, lack of value).
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