The current output for a failed merge with conflict markers looks something like:
merging foo
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
merging bar
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
We're going to change the way merges are done to perform all premerges before
all merges, so that the output above would look like:
merging foo
merging bar
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
The 'warning: conflicts during merge' line has no context, so is pretty
confusing.
This patch will change the future output to:
merging foo
merging bar
warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
that is tricky because we already hint that people run 'hg resolve' to retry
unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
based resolution.
There are two non-interactive internal merge tools, :other and :local,
but they don't really merge, they just pick all changes from the local
or other version of the file. In some situations, it is known that we
want a merge and also know that all merge conflicts should be resolved
in one direction. Although external merge tools can do this, sometimes
it can be convenient to do so from within hg, without invoking a merge
tool. These new :merge-local and :merge-other tools can do just that.
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.
As extensively detailed by Pierre-Yves[1], simplemerge's minimal
markers can result in hopeless confusion for many common merges. As it
happens, we accidentally inherited this behavior when we borrowed
simplemerge from bzr; it is not the behavior used by RCS's merge(1),
Since merge(1) (and not bzr) is what we aim to emulate when emulating
RCS's merge markers, we simply turn this feature off. This brings us
in line with the behavior of CVS, SVN, and Git as a bonus.
(NB: using conflict markers with Mercurial is discouraged.)
[1] http://markmail.org/message/wj5mh3lc46czlvld
convert glob tessa
We are going to introduce a setting to control the "minimisation" feature of
``internal:merge``. So we need more interesting conflicting content. We change
the content in an independent changeset to make sure the coming code change
leave the output unchanged.
Before this patch, filemerge slices byte sequence directly to trim
conflict markers, but this may cause:
- splitting at intermediate multi-byte sequence
- incorrect calculation of column width (length of byte sequence is
different from columns in display in many cases)
This patch uses 'util.ellipsis' to trim custom conflict markers
correctly, even if multi-byte characters are used in them.
Before this patch, with careless configuration (missing '|firstline'
filtering for '{desc}' keyword, for example), '[ui]
mergemarkertemplate' can make conflict markers multiple lines.
For ordinary users, advantage of allowing '[ui] mergemarkertemplate'
to generate multiple lines for customizing seems to be less than
advantage of disallowing it for safety.
This patch uses only the first line of the conflict marker generated
from '[ui] mergemarkertemplate' configuration for safety.
We already have a ":" after the user name to denote the start of the
description. The current usage of quotes around the description is
problematic as the truncation to 80 chars is likely to drop the
closing quote. This may confuse syntax coloration in some editors.
Adds a conflict marker formatter that can produce custom conflict marker
descriptions. It can be set via ui.mergemarkertemplate. The old behavior
can be used still by setting ui.mergemarkers=basic.
The default format is similar to:
{node|short} {tag} {branch} {bookmarks} - {author}: "{desc|firstline}"
And renders as:
contextblahblah
<<<<<<< local: c7fdd7ce4652 - durham: "Fix broken stuff in my feature branch"
line from my changes
=======
line from the other changes
>>>>>>> other: a3e55d7f4d38 master - sid0: "This is a commit to master th...
morecontextblahblah
Without specifying the parent revision of the working copy, users will
update to tip, which is most likely the other head they were trying to
merge, not the revision they were at before the merge.
Many tests fixed the commit date of their changesets at '1000000 0' or
similar. However testing with "Mon Jan 12 13:46:40 1970 +0000" is not
better than testing with "Thu Jan 01 00:00:00 1970 +0000", which is
the default run-tests.py installs.
Removing the unnecessary flag removes some clutter and will hopefully
make it clearer what the tests are really trying to test. Some tests
did not even change their output when the dates were changed, in which
case the -d flag was truly irrelevant.
Dates used in sequence (such as '0 0', '1 0', etc...) were left alone
since they may make the test easier to understand.
