rdamazio@google.com [Wed, 09 Jan 2019 20:00:35 -0800] rev 41146
histedit: crashing with a more useful error message on empty defaultrev
Before this, `hg --config histedit.defaultrev= histedit` would crash with
File "destutil.py", line 385, in desthistedit
if revs:
UnboundLocalError: local variable 'revs' referenced before assignment
Differential Revision: https://phab.mercurial-scm.org/D5543
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:30:30 -0800] rev 41145
progress: check what type of progress bar to use only once per topic
This seems to have sped up `hg perfprogress` from 1.78 s to 1.41 s.
Differential Revision: https://phab.mercurial-scm.org/D5530
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:17:41 -0800] rev 41144
progress: split up _print() method in bar-updating and debug-printing
I just thought this was clearer, but it turned out to also simplify
the next patch.
This seems to have sped up `hg perfprogress` from 1.85 s to 1.78 s.
Differential Revision: https://phab.mercurial-scm.org/D5529
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:12:08 -0800] rev 41143
progress: move cached debug flag from progress.progbar to scmutil.progress
It's simpler this way. One possible drawback (and a possisble
advantage) is that we now check the debug flag once per topic, so
processes that generate new topics all the time will still check the
flag frequently.
Differential Revision: https://phab.mercurial-scm.org/D5528
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Jan 2019 23:55:26 -0800] rev 41142
progress: write ui.progress() in terms of ui.makeprogress()
I think ui.makeprogress() should be the preferred interface and we
should deprecate ui.progress(). All in-core callers already use
ui.makeprogress(). Moving the logic to the scmutil.progress() will let
us make further improvements.
This seems to have sped up `hg perfprogress` from 1.92 s to 1.85 s,
perhaps because we now skip the indirection of updating the progress
bar via ui.progress().
Differential Revision: https://phab.mercurial-scm.org/D5527
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 22:07:47 -0800] rev 41141
testrunner: avoid capturing a regex group we don't care about
Differential Revision: https://phab.mercurial-scm.org/D5536
Kyle Lippincott <spectral@google.com> [Tue, 08 Jan 2019 14:48:05 -0800] rev 41140
remotefilelog: add newlines to ui.log() invocations
The comment at the top of ui.log() says that the message should be a
newline-terminated string. When using the blackbox logger, if the string does
not end in a newline, the appearance in the file gets quite messy.
This sometimes leaves a string with just the newline as the message, these are
logged by the blackbox logger just fine. I don't know what other loggers do when
logging structured data and a message that is just the newline.
Differential Revision: https://phab.mercurial-scm.org/D5533
Augie Fackler <augie@google.com> [Tue, 08 Jan 2019 10:31:10 -0500] rev 41139
xdiff: don't attempt to use fuzzer inputs larger than 100k
This is the recommended approach from [0], and limiting the input was
suggested in https://github.com/google/oss-fuzz/issues/2076 when
discussing our broken coverage build.
0: https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#custom-libfuzzer-options-for-clusterfuzz
Differential Revision: https://phab.mercurial-scm.org/D5525