Matti Hamalainen <ccr@tnsp.org> [Tue, 19 Jun 2018 13:07:18 +0300] rev 38419
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.
Kyle Lippincott <spectral@google.com> [Fri, 02 Feb 2018 14:21:04 -0800] rev 38418
tests: in test-split.t, save a "clean" copy of pre-split repo for later use
Differential Revision: https://phab.mercurial-scm.org/D2015
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 16:01:06 -0700] rev 38417
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:55:38 -0700] rev 38416
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:17:27 -0700] rev 38415
synthrepo: close progress topics
Differential Revision: https://phab.mercurial-scm.org/D3810
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:17:10 -0700] rev 38414
synthrepo: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3809
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:14:39 -0700] rev 38413
largefiles: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3808
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 15:05:52 -0700] rev 38412
convert: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3807
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:59:53 -0700] rev 38411
lfs: use progess helper
Differential Revision: https://phab.mercurial-scm.org/D3806
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:52:41 -0700] rev 38410
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:34:07 -0700] rev 38409
patchbomb: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3804
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:32:12 -0700] rev 38408
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Jun 2018 14:29:08 -0700] rev 38407
churn: use progess helper
Differential Revision: https://phab.mercurial-scm.org/D3802
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:54:58 -0700] rev 38406
treediscovery: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3801
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:48:23 -0700] rev 38405
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:49:27 -0700] rev 38404
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:28:00 -0700] rev 38403
verify: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3798
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:35:49 -0700] rev 38402
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:17:03 -0700] rev 38401
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:13:03 -0700] rev 38400
repair: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3795
Martin von Zweigbergk <martinvonz@google.com> [Sun, 17 Jun 2018 23:11:06 -0700] rev 38399
httpconnection: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D3794
Yuya Nishihara <yuya@tcha.org> [Sun, 03 Jun 2018 18:18:36 +0900] rev 38398
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
Yuya Nishihara <yuya@tcha.org> [Sun, 03 Jun 2018 18:19:54 +0900] rev 38397
byteify-strings: remove superfluous "if True" block
Yuya Nishihara <yuya@tcha.org> [Fri, 01 Jun 2018 00:13:55 +0900] rev 38396
byteify-strings: try to preserve column alignment
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 23:44:35 +0900] rev 38395
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.
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:34:23 +0900] rev 38394
byteify-strings: do not rewrite iteritems() and itervalues() by default
We can't do that automatically due to performance concerns.
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:31:37 +0900] rev 38393
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.
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:28:29 +0900] rev 38392
byteify-strings: add --inplace option to write back result
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:23:30 +0900] rev 38391
byteify-strings: add basic command interface
Yuya Nishihara <yuya@tcha.org> [Thu, 31 May 2018 22:07:04 +0900] rev 38390
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.