view tests/test-eol-tag.t @ 39037:ede768cfe83e

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

https://bz.mercurial-scm.org/2493

Testing tagging with the EOL extension

  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > eol =
  > 
  > [eol]
  > native = CRLF
  > EOF

setup repository

  $ hg init repo
  $ cd repo
  $ cat > .hgeol <<EOF
  > [patterns]
  > ** = native
  > EOF
  $ printf "first\r\nsecond\r\nthird\r\n" > a.txt
  $ hg commit --addremove -m 'checkin'
  adding .hgeol
  adding a.txt

Tag:

  $ hg tag 1.0

Rewrite .hgtags file as it would look on a new checkout:

  $ hg update -q null
  $ hg update -q

Touch .hgtags file again:

  $ hg tag 2.0

  $ cd ..