Tue, 19 Jun 2018 13:07:18 +0300 crecord: re-center display in interactive curses commit on pageup/down
Matti Hamalainen <ccr@tnsp.org> [Tue, 19 Jun 2018 13:07:18 +0300] rev 38413
crecord: re-center display in interactive curses commit on pageup/down A long-standing issue in the crecord (interactive curses commit interface) is that using PageUp/Down to move along longer-than current screen size chunks would "lose" the cursor and not properly re-center. There has been self.recenterdisplayedarea() to do that, but it has not been in use for some reason. Add calls to the appropriate uparrowshiftevent() and downarrowshiftevent() methods to fix this.
Fri, 02 Feb 2018 14:21:04 -0800 tests: in test-split.t, save a "clean" copy of pre-split repo for later use
Kyle Lippincott <spectral@google.com> [Fri, 02 Feb 2018 14:21:04 -0800] rev 38412
tests: in test-split.t, save a "clean" copy of pre-split repo for later use Differential Revision: https://phab.mercurial-scm.org/D2015
Mon, 18 Jun 2018 16:01:06 -0700 tests: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 16:01:06 -0700] rev 38411
tests: use progress helper With this commit, the only in-tree caller of ui.progress() is scmutil.progress(). That means that we could deprecate it. It also means that we can considering inlining it in scmutil.progress. Differential Revision: https://phab.mercurial-scm.org/D3812
Mon, 18 Jun 2018 15:55:38 -0700 changegroup: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:55:38 -0700] rev 38410
changegroup: use progress helper Although it looks like this code was micro-optimized, I could not measure any slow-down. Differential Revision: https://phab.mercurial-scm.org/D3811
Mon, 18 Jun 2018 15:17:27 -0700 synthrepo: close progress topics
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:17:27 -0700] rev 38409
synthrepo: close progress topics Differential Revision: https://phab.mercurial-scm.org/D3810
Mon, 18 Jun 2018 15:17:10 -0700 synthrepo: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:17:10 -0700] rev 38408
synthrepo: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3809
Mon, 18 Jun 2018 15:14:39 -0700 largefiles: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:14:39 -0700] rev 38407
largefiles: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3808
Mon, 18 Jun 2018 15:05:52 -0700 convert: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:05:52 -0700] rev 38406
convert: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3807
Mon, 18 Jun 2018 14:59:53 -0700 lfs: use progess helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:59:53 -0700] rev 38405
lfs: use progess helper Differential Revision: https://phab.mercurial-scm.org/D3806
Mon, 18 Jun 2018 14:52:41 -0700 relink: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:52:41 -0700] rev 38404
relink: use progress helper This doesn't use progress.increment() because progress output is skipped for some positions (so we may end up calling "update(0), update(2), update(7)", or similar). Differential Revision: https://phab.mercurial-scm.org/D3805
Mon, 18 Jun 2018 14:34:07 -0700 patchbomb: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:34:07 -0700] rev 38403
patchbomb: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3804
Mon, 18 Jun 2018 14:32:12 -0700 patchbomb: don't close unused progress topic
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:32:12 -0700] rev 38402
patchbomb: don't close unused progress topic The "writing" topic has not been used since 1830d0cc4bc1 (patchbomb: minor refactoring of mbox functionality, preparing for move, 2011-11-23). Differential Revision: https://phab.mercurial-scm.org/D3803
Mon, 18 Jun 2018 14:29:08 -0700 churn: use progess helper
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:29:08 -0700] rev 38401
churn: use progess helper Differential Revision: https://phab.mercurial-scm.org/D3802
Sun, 17 Jun 2018 23:54:58 -0700 treediscovery: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:54:58 -0700] rev 38400
treediscovery: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3801
Sun, 17 Jun 2018 23:48:23 -0700 upgrade: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:48:23 -0700] rev 38399
upgrade: use progress helper A minor side-effect is that we no longer print the progress at 0 (and that we don't re-print it at its current value when starting the next manifest/file). Differential Revision: https://phab.mercurial-scm.org/D3800
Sun, 17 Jun 2018 23:49:27 -0700 upgrade: close progress after each revlog
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:49:27 -0700] rev 38398
upgrade: close progress after each revlog IIUC, one is supposed to close each progress topic before strarting a new one. Otherwise the topics are considered nested, which we don't want here. Differential Revision: https://phab.mercurial-scm.org/D3799
Sun, 17 Jun 2018 23:28:00 -0700 verify: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:28:00 -0700] rev 38397
verify: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3798
Sun, 17 Jun 2018 23:35:49 -0700 verify: use progress helper for subdirectory progress
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:35:49 -0700] rev 38396
verify: use progress helper for subdirectory progress I also reworded a variable to make it clearer that it's only used for subdirectories. Differential Revision: https://phab.mercurial-scm.org/D3797
Sun, 17 Jun 2018 23:17:03 -0700 similar: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:17:03 -0700] rev 38395
similar: use progress helper A side-effect is that progress is now reported as 1 *before* we start checking the first file. That seems to be how we do it in most places. Also, the right topic is now closed. Differential Revision: https://phab.mercurial-scm.org/D3796
Sun, 17 Jun 2018 23:13:03 -0700 repair: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:13:03 -0700] rev 38394
repair: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3795
Sun, 17 Jun 2018 23:11:06 -0700 httpconnection: use progress helper
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:11:06 -0700] rev 38393
httpconnection: use progress helper Differential Revision: https://phab.mercurial-scm.org/D3794
Sun, 03 Jun 2018 18:18:36 +0900 py3: byte-stringify literals in contrib/phabricator.py as example
Yuya Nishihara <yuya@tcha.org> [Sun, 03 Jun 2018 18:18:36 +0900] rev 38392
py3: byte-stringify literals in contrib/phabricator.py as example Transformed by contrib/byteify-strings.py and adjusted exceeded lines manually. Some of b''s would be wrong as the phabriactor extension has to work with JSON data. # skip-blame just many b prefixes
Sun, 03 Jun 2018 18:19:54 +0900 byteify-strings: remove superfluous "if True" block
Yuya Nishihara <yuya@tcha.org> [Sun, 03 Jun 2018 18:19:54 +0900] rev 38391
byteify-strings: remove superfluous "if True" block
Fri, 01 Jun 2018 00:13:55 +0900 byteify-strings: try to preserve column alignment
Yuya Nishihara <yuya@tcha.org> [Fri, 01 Jun 2018 00:13:55 +0900] rev 38390
byteify-strings: try to preserve column alignment
Thu, 31 May 2018 23:44:35 +0900 byteify-strings: do not rewrite system string literals to u''
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 23:44:35 +0900] rev 38389
byteify-strings: do not rewrite system string literals to u'' It would make things worse on Python 2 because unicode processing is generally slower than byte string. We should just leave system strings unmodified.
Thu, 31 May 2018 22:34:23 +0900 byteify-strings: do not rewrite iteritems() and itervalues() by default
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:34:23 +0900] rev 38388
byteify-strings: do not rewrite iteritems() and itervalues() by default We can't do that automatically due to performance concerns.
Thu, 31 May 2018 22:31:37 +0900 byteify-strings: drop import-line hack
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:31:37 +0900] rev 38387
byteify-strings: drop import-line hack This is ugly, and valid only for Python 3. We'll need to find a different way if we want to get rid of the code transformer at all.
Thu, 31 May 2018 22:28:29 +0900 byteify-strings: add --inplace option to write back result
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:28:29 +0900] rev 38386
byteify-strings: add --inplace option to write back result
Thu, 31 May 2018 22:23:30 +0900 byteify-strings: add basic command interface
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:23:30 +0900] rev 38385
byteify-strings: add basic command interface
Thu, 31 May 2018 22:07:04 +0900 byteify-strings: fork py3 code transformer to make it a standalone command
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:07:04 +0900] rev 38384
byteify-strings: fork py3 code transformer to make it a standalone command I'm thinking of making a one-off s/''/b''/g change for overall codebase to make linter happy. We could do that without maintaining the script, but I think it will be somewhat useful for extension authors. So it is in contrib.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip