JavaScript .replace always magically processed $$ $& $' $` in replacement
strings and thus displayed subject lines incorrectly in the graph view.
Instead of regexps and .replace we now just create the strings the right way in
the first place.
If all heads are bookmarks, merge fails to find what node to merge
with (throws an IndexError while indexing into the non-bookmark heads
list) as of 208ca72b9343. This catches that case and prints an error
to specify a rev explicitly.
When running:
$ hg debugfileset 'binary() and ignored()'
getfileset() was correctly retrieving ignored files but
matchctx.existing() was not taking them in account. Just add them along
with unknown files.
By default, unknown files are ignored. If the 'unknown()' predicate
appears in the syntax tree, then they are taken in account.
Unfortunately, matchctx.existing() was filtering against non-deleted
context files, which does not include unknown files. So:
$ hg debugfileset 'binary() and unknown()'
would not return existing binary unknown files.
Running:
$ hg debugfileset 'binary()'
would traceback if there were one deleted file in the working directory.
It happened because matchctx.existing() was filtering files against the
ctx.__contains__() but deleted files are still considered part of
workingctx.
Avoid mixing popen and subprocess calls, it simplifies the command line
generation and quoting issues with redirections.
In practice, it fixes the subversion sink on Windows and probably helps
with monotone and darcs sources.
The `repair` code builds a giant revset query instead of using the "%lr" idiom.
It is inefficient and crash when the number of stripped changeset is too big.
This changeset replaces the bad code by a better revset usage.
_partialmatch() does prefix matching against nodes. String passed
to _partialmetch() actualy may be any string, not prefix only.
For example,
"63af8381691a9e5c52ee57c4e965eb306f86826e or 300" is a good
argument for _partialmatch().
When _partialmatch() searches using radix tree, index_partialmatch()
C function shouldn't try to match too long strings.
The standard reaction in from of unexpected vimdiff is to ":quit". This will
make vimdiff return a 0 status even if no merge were done at all.
This change detect that nothing have been changed in vimdiff as a potential
unresolved conflict.
This makes it possible to do lock validation as part of a normal test
run. I didn't attempt any wlock validation because that's a bit more
subtle to detect properly. Thanks to the initial patch from Mads for
the idea.
At the moment the resolve command doesn't save progress during the resolve process. In example if you try to resolve 100 conflicting files and interrupt the process (e.g., you close the external merge tool) after resolving 50 files you'll end up with 100 unresolved conflicts. Saving the progress helps a lot with long going merges. It's easy to achieve same behavior with simple script that calls resolve command for each unresolved file but it makes sense to make such behavior a default
Before this patch, the argument bound to the source repository of
incoming bookmarks for "bookmarks.diff()" is named as "remote".
But in "hg outgoing" case, this argument is bound to local repository
object.
In addition to it, "local"/"remote" seem to mean not the direction of
propagation of bookmarks, but just the location of cooperative
repositories.
To indicate the direction of propagation of bookmarks clearly on the
source code, this patch uses "d(st)" and "s(rc)" combination instead
of "l(ocal)" and "r(emote)" one.
- "repo" and "remote" arguments are renamed to "dst" and "src"
- "lmarks" and "rmarks" variables are renamed to "dmarsk" and "smarks"
When histedit "continue", there is several complicated logic to apply in order to
detect intermediate changeset and concluded pending operation.
This changeset extract this logic in a dedicated function to lighten the main
one. No alteration to the logic is done.
