Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 23:13:01 -0400] rev 39079
grep: coerce username to bytestr, not str
Differential Revision: https://phab.mercurial-scm.org/D4238
Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 23:12:44 -0400] rev 39078
grep: difflib sequencematcher opcodes are native strs
Differential Revision: https://phab.mercurial-scm.org/D4237
Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 21:59:32 -0400] rev 39077
tests: allow for a bonus newline in base64'd email payload
Python 3 adds this newline, which is harmless.
test-patchbomb.t now passes on Python 3.
Differential Revision: https://phab.mercurial-scm.org/D4234
Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 21:58:43 -0400] rev 39076
mail: be more cautious about bytes vs str for py3 compat
It's suboptimal that we get a bytes on 2 and a unicode on 3, but it's
easy to work with and I'm disinclined to change anything unless we
start using some sort of type inferencer.
Differential Revision: https://phab.mercurial-scm.org/D4233
Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 21:57:46 -0400] rev 39075
patchbomb: use native strings when determining attachment disposition
Differential Revision: https://phab.mercurial-scm.org/D4232
Augie Fackler <augie@google.com> [Thu, 09 Aug 2018 21:04:15 -0400] rev 39074
mail: always fall back to iso-8859-1 if us-ascii won't work (BC)
It looks like this was a well-intentioned backwards compat hack for
previewing the output of `hg email` in a stable way. Unfortunately I
think this hack's time has come, because Python 3 does a much better
job of ensuring it actually emits *valid* email messages. In
particular, Python 2 would blindly trust us that the bytes we handed
it were valid for the encoding we claimed, but Python 3 has some more
sniff-tests that we end up failing.
As a result, if we're going to print an email to the terminal, try
us-ascii first, but if that fails go straight to iso-8859-1 which
should be reasonably readable for ascii-compatible patch bodies. This
*will* be a breaking change for ascii-incompatible textual patch
content, but I don't think that's avoidable if we want to continue
using the email library from the stdlib.
.. bc::
Emails from the patchbomb extension will always be printed as though
they are iso-8859-1 if they're not valid us-ascii. Previously,
previewed emails were always claimed to be us-ascii and might
contain invalid byte sequences.
Differential Revision: https://phab.mercurial-scm.org/D4231