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.
_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.
Displaying multiple synopsis in online help has been broken since Matt
RST refactoring, around 54e90eb99cfa. Rebase help is apparently the only
one using this trick, just drop the second synopsis and assume people
will understand as with graft help.
This restores the old behaviour of clearing the filecache when the repo is
destroyed but combines it with also clearing it on _rollback. Before, we tried
to only call it through _rollback but that ruined callers of destroyed.
Doing it on both code paths covers destroyed being called from somewhere
else, e.g. strip.
This makes the 'additional help topics' list consistent with the output from
keyword search (for instance subrepo/subrepos).
The sorting by longest name was introduced in 4cbe49492ad3. There might have
been a good reason for it back then, but now it seems like a better idea to
place the preferred name first in the list in helptable.
If patch.patch() reports patched files when applying a changeset and the
following commit says nothing changed, transplant used to abort with a
RuntimeError, assuming something went wrong with patching.
The mismatch is patch.patch() reports patched files, not changed ones.
It could be modified to report changed files but it means duplicating
work from status, may be expensive in the case of binary files, and is
probably not that useful at API level. For instance, if two patches are
applied on the working directory, the outcome may be nothing changed
while each call would have returned modified files. The caller would
have to call status() itself again.
This patch fixes the issue by trusting patching code: if the patch
succeeded and commit reports nothing changed, then nothing changed,
patch() did not "dropped changes on the floor".
- Fix off-by-one error on displayed entries count in normal mode
- Fix incorrect paging when the top revision was lower than revcount
- Fix revcount not overriding web.maxshortchanges everywhere
"i18n.gettext()" invocation for "editcomment" itself should have
little impact for whole initialization cost of histedit, because it is
already invoked for initialization of the command table entry.
'\n\n' has to be added to the text being edited separately from
"editcomment", because leading 'line feed' characters are not exported
to "hg.pot" file correctly.
Using less -S will hide possibly important information when reviewing a
changeset, e.g. something wrong/dangerous after the 80th column, because
"less" will not give an indication that following characters are hidden.
Previously, the parents / children were computed relative to the cset of the
currently shown file, which was wrong and inconsistent with diff and others.
With this patch, the listed csets are those that contain changes to the
currently compared file, which don't necessarily have to be the direct parents
and children of the changeset itself.
The top-level 'comparison' template was not really needed, and it also caused a
traceback to be shown for inexistent files (as reported by Ross Lagerwall).
Getting rid of it makes the overall templating structure simpler and causes
invalid files to be handled nicely.
