help: branch names primarily denote the tipmost unclosed branch head
Was the behavior correct and the description wrong so it should be updated as
in this patch? Or should the code work as the documentation says?
Both ways could make some sense ... but none of them are obvious in all cases.
One place where it currently cause problems is when the current revision has
another branch head that is closer to tip but closed. 'hg rebase' refuses to
rebase to that as it only see the tip-most unclosed branch head which is the
current revision.
/me kind of likes named branches, but no so much how branch closing works ...
util: introduce util.debugstacktrace for showing a stack trace without crashing
This is often very handy when hacking/debugging.
Calling util.debugstacktrace('hey') from a place in hg will give something like:
hey at:
./hg:38 in <module>
/home/user/hgsrc/mercurial/dispatch.py:28 in run
/home/user/hgsrc/mercurial/dispatch.py:65 in dispatch
/home/user/hgsrc/mercurial/dispatch.py:88 in _runcatch
/home/user/hgsrc/mercurial/dispatch.py:740 in _dispatch
/home/user/hgsrc/mercurial/dispatch.py:514 in runcommand
/home/user/hgsrc/mercurial/dispatch.py:830 in _runcommand
/home/user/hgsrc/mercurial/dispatch.py:801 in checkargs
/home/user/hgsrc/mercurial/dispatch.py:737 in <lambda>
/home/user/hgsrc/mercurial/util.py:472 in check
...
check-code: drop now unused check-code-ignore
Using check-code-ignore to skip the failures on a line has several
disadvantages:
* It skips all check-code failures on a line, not only the one it was created
for.
* It does not give any hint for which rule it was added, making it difficult to
see when it is not needed anymore.
So drop this pragma in favor of better alternatives promoted before.
check-code: explain what to do when a check-code rule mismatches
In the past several approaches were used when a check-code rule triggered
without a good reason. Not all of them looked nice, some were even wrong.
Suggest some good practices which should be used instead.
cleanup: Remove the only ever used skip-check-code pragma
Use the work-around suggested by the rule instead
check-code: always report when a file is skipped by "no-check-code"
Skipping an entire file generally from checking is an important event, so
report it always.
Do not tell the check name because skipping does not depend on it. Directly
skip the entire file instead of checking more patterns and skip again.
The pragma no-check-code was introduced by accident in the past. (Fixed in
e033a7d444ac and
ee07f9d142c9.) This now is prevented because the files
to skip have to be listed in the test output of test-check-code-hg.t.
check-code: do not skip entire file, skip only one match instead
Skipping of the entire file has been introduced in
bc3b48b0f5c8.
bisect: --command without --noupdate should flag the parent rev it tested
14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it
also changed how the 'current' revision is used in combination with --command.
The new behaviour might be ok for --noupdate where the working directory and
its revision shouldn't be used, but it also did that when --command is used to
run a command on the currently checked out revision then it could register the
test result on the wrong revision.
An example:
Before, bisect with --command could use the wrong revision when recording the
test result:
$ hg up -qr 0
$ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
changeset 31:
58c80a7c8a40: bad
abort: inconsistent state, 31:
58c80a7c8a40 is good and bad
Now it works as before and as expected and uses the working directory revision
for the --command result:
$ hg up -qr 0
$ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
changeset 0:
b99c7b9c8e11: bad
...
context: drop caching 'copies' method
The 'copies' method has no test coverage and calls copies.pathcopies with an
incorrect number of parameters and is thus (fortunately) not used. Kill it.
commands.bookmarks: move hexfn to inside list block
This isn't used outside this block, nor is it expected to be.