Aliased commands that received bad arguments would raise TypeError instead of
SignatureError. This only affected commands that weren't wrapped by extensions.
Using util.checksignature() in cmdalias.__call__() ensures SignatureError is
raised correctly.
Previous behavior wasn't very helpful:
$ hg st foo
abort: No such file or directory
Now we tell more about what failed:
abort: error getting current working directory: No such file or directory
(makes issue2135, issue2264 more obvious, but does nothing to fix
either one)
This seems to happen in two distinct cases:
* patch.patch() claims success but changes nothing (e.g.
the transplanted changeset adds an empty file that already
exists)
* patch.patch() makes changes, but repo.status() fails to report them
Both of these seem like bugs in other parts of Mercurial, so arguably
it's not transplant's job to detect the failure to commit. However:
* detecting the problem as soon as possible is desirable
* it prevents a more obscure crash later, in transplants.write()
* there might be other lurking (or future) bugs that cause
repo.commit() to do nothing
Also, in the case of issue2264 (source changesets silently dropped by
transplant), the only way to spot the problem currently is the crash
in transplants.write(). Failure to transplant a patch should abort
immediately, whether it's user error (patch does not apply) or a
Mercurial bug (e.g. repo.status() failing to report changes).
stripping of applied mq patches leads to wrong state recorded in status
file. find all mq patches that will be affected and clean up status file
before strip.
When addbranchrevs extends revs, it adds changeset hashes, and not node ids.
Which means that we have to lookup for revisions _after_ the addbranchrevs
call, instead of before.
By renaming before reverting the content of the file we ensure that we handle
and break hardlinks properly.
Handling of other hardlinks to .orig is somebody elses problem.
This makes it consistent with dirstate.status(), which is important if
there are other extensions messing with the output of status(). Those
extensions can safely assume that dirstate.status() returns a tuple of
lists, because its docstring says it does. But
inotifystatus.dirstate() returns a list of lists, which can break
those other extensions.
Branches can have multiple heads, so it doesn't make sense to speak of "the
head of the current branch". What update really does is try to update to the
*tip* of the current branch.
Some encoding and language combinations (e.g.: UTF-8 and Japanese)
cause encoding characters into sequence of bytes more than column
width of them.
So, encoding.colwidth() should be applied instread of len() on i18n
strings.
In addition to it, formatting by '%*s'/'%-*s' also uses "number of
bytes" to calculate space padding size, and should be fixed, too.
To test f02da4369319 we analyze this repo:
0 | 1 | 2 | 3 | 4
a ------------> b
\
b -> dir/b -------> e
d
We follow dir/b and expects rev 0, 1 and 2.
A log following b will surprisingly report rev 0 and 1. That's because the
content and the parents are the same in rev 1 and rev 3, and the revlog entry
from rev 1 is thus reused in rev 3 even though the revlink is incorrect.
Note that if we follow e then we will get all revs, including rev 3, because b
gets added to the set of interesting filenames we are following through all
revisions. That might be surprising, but that's (currently) how it is.
Original test case by Joel Rosdahl <joel@rosdahl.net>
Original test reviewed by Nicolas Dumazet <nicdumz@gmail.com>
This resolves the issue of hg cmd --mq not being colorized. This was due
to color wrapping only the instance of ui passed to dispatch._runcommand(),
which isn't the same ui object that mq.mqcommand() receives. After dispatch
calls extensions.loadall(), it makes sure any changes to ui.__class__ in
uisetup are propagated.
progress is updated to wrap ui in the same manner because wrapfunction
doesn't play well when ui.__class__ has been replaced by another extension
(orig will point to the old class method instead of color's).
Clarify that:
- Specified paths are matched by comparing name of file or directory.
- Line order (thus) doesn't matter.
- Rename doesn't imply include.
When commiting, a check is made to see if one of the parents is a
closed head. However this did not check that the branch of the commit
is the same as the closed head, so one could get a warning message on
the sequence
hg commit --close-branch
hg branch new-branch
hg commit
or when merging in a closed head.
With inotify enabled, files that should be ignored could be detected as
untracked by mercurial. This behavior was wrong because inotify's filestatus
implementation only matched filenames against ignore patterns, instead of
checking if other elements of their paths matched them. This patch fixes the
behavior by checking the file paths against the ignore patterns.
A new test has also been added to the main inotify test to prevent any
regressions.
Since d6ca622d1122 the branch argument for addbranchrevs should be a tuple:
(hashbranch, branches)
The right empty value therefore is (None, []) instead of None.
filelog.renamed() is an expensive call as it reads the filelog if p1 == nullid.
It's more efficient to first compute the hash, and to bail early if
the computed hash is the same as the stored nodeid.
'samehashes' variable is not strictly necessary, but helps for comprehension.
Because "\1\n" is a separator for metadata, data starting with "\1\n" is
handled specifically. It was not tested.
size() call return incorrect data if original data had been "\1\n-escaped".
There's no obvious way to fix it for now, just flag the error in the code
and add an "expected failure" kind of test.
This is similar to the __builtin__.cmp behaviour, but still not
straightforward, as the dailylife meaning of a comparison usually is
"find out if they are different".
Apparently we mostly used filectx.cmp(workingfilectx.read()), so no error
was ever triggered, but since all cmp() methods return True when content
are different, that == should in fact be !=
