Mads Kiilerich <madski@unity3d.com> [Sun, 17 Nov 2013 18:21:58 -0500] rev 20246
rebase: test for empty dest revision
Mads Kiilerich <madski@unity3d.com> [Thu, 21 Nov 2013 15:17:18 -0500] rev 20245
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 ...
Mads Kiilerich <madski@unity3d.com> [Sun, 12 Jan 2014 23:28:21 +0100] rev 20244
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
...
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:57 +0100] rev 20243
check-code: print debug output when an ignore pattern matches
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:51 +0100] rev 20242
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.
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:44 +0100] rev 20241
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.