Sat, 13 Jul 2013 17:43:19 +0400 hgweb: make stripes in bookmark list with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:43:19 +0400] rev 19446
hgweb: make stripes in bookmark list with CSS
Thu, 18 Jul 2013 16:29:05 -0500 tests: update for commit --secret
Matt Mackall <mpm@selenic.com> [Thu, 18 Jul 2013 16:29:05 -0500] rev 19445
tests: update for commit --secret
Sun, 14 Jul 2013 21:50:52 +0800 gpg: show "Unknown key ID xxxxxxxx" when the status is ERRSIG
Wei, Elson <elson.wei@gmail.com> [Sun, 14 Jul 2013 21:50:52 +0800] rev 19444
gpg: show "Unknown key ID xxxxxxxx" when the status is ERRSIG
Sun, 14 Jul 2013 21:50:45 +0800 gpg: add shortkey() to convert from long id to short
Wei, Elson <elson.wei@gmail.com> [Sun, 14 Jul 2013 21:50:45 +0800] rev 19443
gpg: add shortkey() to convert from long id to short
Fri, 12 Jul 2013 10:10:46 +0800 gpg: getkeys() removes unused returning value "err"
Wei, Elson <elson.wei@gmail.com> [Fri, 12 Jul 2013 10:10:46 +0800] rev 19442
gpg: getkeys() removes unused returning value "err"
Fri, 12 Jul 2013 10:05:11 +0800 gpg: treat "ERRSIG" as a valid key id but no fingerprint
Wei, Elson <elson.wei@gmail.com> [Fri, 12 Jul 2013 10:05:11 +0800] rev 19441
gpg: treat "ERRSIG" as a valid key id but no fingerprint
Thu, 11 Jul 2013 13:11:41 -0400 commit: enable --secret option
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 11 Jul 2013 13:11:41 -0400] rev 19440
commit: enable --secret option At the moment, creating secret commits is slightly cumbersome. They can either be created by changing the default commit phase to secret or by doing `hg phase --secret --force`. Both of these make secret commits appear to be like some kind of advanced feature. Secret commits, however, should be a convenient feature for people who want to work on a private branch without affecting anyone else. There should therefore be a prominent and convenient method for creating secret commits. Since the default phase is draft and there is no need to use --force to go from a secret phase to any other phase, this patch intentionally does not add --draft and --public options.
Wed, 17 Jul 2013 23:58:04 +0200 merge: deprecate the --force option
Florence Laguzet <florence.laguzet@gmail.com> [Wed, 17 Jul 2013 23:58:04 +0200] rev 19439
merge: deprecate the --force option The --force option in merge does not make what people think it does so it may not be visible to everyone. I have local changes and want to pull one's changes which made 2 heads. The --force option in help says -f --force force a merge with outstanding changes so I can expect that I can use it to force the merge and commit it in my local repository without taking my local changes into account. But merging with -f keeps local changes and "add" them: they must be committed or reverted before doing the merge commit. The merge -f cannot be reverted so it leads my repository in a bad state: cannot commit merge and don't want to revert/commit local changes yet. Message in help have been updated to emphasize the fact that local changes are included in the merge.
Thu, 18 Jul 2013 09:42:44 -0700 run-tests: revert previous commit, run() waits after a timeout
Brendan Cully <brendan@kublai.com> [Thu, 18 Jul 2013 09:42:44 -0700] rev 19438
run-tests: revert previous commit, run() waits after a timeout
Thu, 18 Jul 2013 09:39:01 -0700 run-tests: reap timed-out zombies
Brendan Cully <brendan@kublai.com> [Thu, 18 Jul 2013 09:39:01 -0700] rev 19437
run-tests: reap timed-out zombies
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip