Commit fbcca4a9d1 changed a grep command in an attempt to prevent a
false positive, that is, to prevent grep from matching python code not
actually using the banned 'past' module. Problem is, (?!e) is not valid
syntax unless grep was compiled with support for Perl Compatible Regular
Expressions. However, we can use extended regexp syntax to avoid the
false positive. While we're at it, let's make similar improvements to
the other regular expressions to prevent more false positives.
fatal: ambiguous argument 'tools/cpep8.manifest': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
This makes us grab the "percent in common" stat for the new file being
added instead of just looking at the "percent changed" for the old one.
The latter ignores what may be a large amount of things considered to
be deleted, making the change amount look larger.
Long ago, an anti-pattern was introduced by a driver whereby the prompt
string were marked for translation, but wrapped around a call to
dedent() for formatting. In order for gettext to pick up the strings
when building the catalog, the actual literals must be marked. Even
though the gettext call works at runtime, the static analysis does not
understand enough python to push through that call.
This is the first step of re-writing all those instances to avoid
using dedent() and instead use multiple string lines inside the gettext
call. This was done en masse, so it's possible that some of this is
not right, but it's a good start and much more reasonable than doing
it manually in so many places.
This also includes a dumb rule in check_commit.sh to help prevent
future introduction of this, although it won't catch all cases.
Related to #10434
