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
Brendan Cully <brendan@kublai.com> [Thu, 18 Jul 2013 09:39:01 -0700] rev 19437
run-tests: reap timed-out zombies
Alexander Plavin <me@aplavin.ru> [Fri, 12 Jul 2013 01:58:48 +0400] rev 19436
hgweb: run search instead of showing wrong error for ambigious identifier
Before this when multiple changesets hashes in the repos started with the
search query string, error was given that the revision isn't found, and it
was misleading. Now a simple keyword search runs in this case.