Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:44:46 +0400] rev 19447
hgweb: make stripes in directory view 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
Matt Mackall <mpm@selenic.com> [Thu, 18 Jul 2013 16:29:05 -0500] rev 19445
tests: update for commit --secret
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
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
Wei, Elson <elson.wei@gmail.com> [Fri, 12 Jul 2013 10:10:46 +0800] rev 19442
gpg: getkeys() removes unused returning value "err"
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
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.
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.
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