Sat, 13 Jul 2013 17:31:53 +0400 hgweb: change highlighted line color to be different from 'inserted' color
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:31:53 +0400] rev 19458
hgweb: change highlighted line color to be different from 'inserted' color This changes line highlight color from a fain yellow (#ffff99) to a faint blue (#bfdfff), because yellow color is used in comparison view for inserted lines. This new color is okay for people with different forms of color blindness (tested with a simulator): a) this color looks quite different from other used backgrounds b) text doesn't lose distinction on this color
Fri, 19 Jul 2013 01:40:57 +0200 convert: fix bad conversion of copies when hg.startrev is specified
Mads Kiilerich <madski@unity3d.com> [Fri, 19 Jul 2013 01:40:57 +0200] rev 19457
convert: fix bad conversion of copies when hg.startrev is specified The 'copynode' was looked up in self.keep as if it was a changeset node. It is however a filelog node, and self.keep would thus fail if it actually looked at its parameter ... which it only did if a startrev was specified. Instead we now don't check the copy node - we don't have to. It must have been copied from one of the parents, and we already check whether one of the parents have the copy source. We could perhaps use linkrev to see if the corresponding changeset was converted ... but that would sometimes be wrong. The existing test of this was wrong - now it is better, but it seems like it exposes a 'log' issue.
Fri, 19 Jul 2013 01:18:15 +0200 test-convert-hg-startrev: fix test for copy removal on missing parent
Mads Kiilerich <madski@unity3d.com> [Fri, 19 Jul 2013 01:18:15 +0200] rev 19456
test-convert-hg-startrev: fix test for copy removal on missing parent The test assumed that 'b' was missing just because the changeset that introduced 'b' wasn't converted ... but 'b' was also not removed before the start revision, and the parent was thus not missing at all. Instead we introduce a file 'f' in rev 0 and remove it in rev 1 so the copy source really doesn't exist in the repo that is converted from rev 1.
Sat, 13 Jul 2013 18:06:57 +0400 hgweb: make stripes in diffstat with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 18:06:57 +0400] rev 19455
hgweb: make stripes in diffstat with CSS
Sat, 13 Jul 2013 18:03:35 +0400 hgweb: make stripes in file log with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 18:03:35 +0400] rev 19454
hgweb: make stripes in file log with CSS
Sat, 13 Jul 2013 18:02:34 +0400 hgweb: make stripes in graph with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 18:02:34 +0400] rev 19453
hgweb: make stripes in graph with CSS
Sat, 13 Jul 2013 17:59:00 +0400 hgweb: make stripes in log and search with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:59:00 +0400] rev 19452
hgweb: make stripes in log and search with CSS
Sat, 13 Jul 2013 17:51:43 +0400 hgweb: make stripes in branch list with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:51:43 +0400] rev 19451
hgweb: make stripes in branch list with CSS
Sat, 13 Jul 2013 17:49:20 +0400 hgweb: make stripes in repo list with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:49:20 +0400] rev 19450
hgweb: make stripes in repo list with CSS
Sat, 13 Jul 2013 17:43:45 +0400 hgweb: make stripes in file annotate view with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:43:45 +0400] rev 19449
hgweb: make stripes in file annotate view with CSS
Sat, 13 Jul 2013 17:44:57 +0400 hgweb: make stripes in tag list with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:44:57 +0400] rev 19448
hgweb: make stripes in tag list with CSS
Sat, 13 Jul 2013 17:44:46 +0400 hgweb: make stripes in directory view with CSS
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:44:46 +0400] rev 19447
hgweb: make stripes in directory view with CSS
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
Fri, 12 Jul 2013 01:58:48 +0400 hgweb: run search instead of showing wrong error for ambigious identifier
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.
Wed, 17 Jul 2013 17:34:47 -0700 doc: bump copyright year
Siddharth Agarwal <sid0@fb.com> [Wed, 17 Jul 2013 17:34:47 -0700] rev 19435
doc: bump copyright year
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip