We are about to remove the branchmap cache update in changegroup application.
There is a debug message alongside this update that we do not want to loose. We
move the message beforehand to simplify the test update in the next changeset.
The message move is quite noisy and isolating that noise is useful.
Most tests update are just line reordering since the message is issued at a
later point during the transaction.
After this changes, the message is displayed in more case since local commit
creation also issue it.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
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.
Previously, we had weird, nonsensical behavior when committing a file move
with a missing source. This removes that weird logic and tests that the bug
this strange behavior caused is fixed. Also adds a longish comment to prevent
some poor soul from accidentally re-implementing the bug in the future.
commitctx already showed notes with filenames but didn't provide any context.
It is just as relevant to know when manifest or changelog is committed.
So, in addition to filenames, also show headlines 'committing files:',
'committing manifest' and 'committing changelog'.
'export' is the official export format and used by patchbomb, but it would only
show date as a timestamp that most humans might find it hard to relate to. It
would be very convenient when reviewing a patch to be able to see what
timestamp the patch will end up with.
Mercurial has always used util.parsedate for parsing these headers. It can
handle 'all' date formats, so we could just as well use a readable one.
'export' will now use the format used by 'log' - which is the format described
as 'Unix date format' in the templating help. We assume that all parsers of '#
HG changeset patch'es can handle that.
See the Hg Book on why we actually want to detect this case:
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id364290
Before:
$ hg up deadbeef
warning: detected divergent renames of X to:
...
After:
$ hg up deadbeef
note: possible conflict - X was renamed multiple times to:
...
No functionality change.
