On Thu, Nov 07, 2019 at 09:56:15AM +0700, Doan Tran Cong Danh wrote:
> On musl libc, ISO-2022-JP encoder is too eager to switch back to
> 1 byte encoding, musl's iconv always switch back after every combining
> character. Comparing glibc and musl's output for this command
> $ sed q t/t3900/ISO-2022-JP.txt| iconv -f ISO-2022-JP -t utf-8 |
> iconv -f utf-8 -t ISO-2022-JP | xxd
>
> glibc:
> 00000000: 1b24 4224 4f24 6c24 5224 5b24 551b 2842 .$B$O$l$R$[$U.(B
> 00000010: 0a .
>
> musl:
> 00000000: 1b24 4224 4f1b 2842 1b24 4224 6c1b 2842 .$B$O.(B.$B$l.(B
> 00000010: 1b24 4224 521b 2842 1b24 4224 5b1b 2842 .$B$R.(B.$B$[.(B
> 00000020: 1b24 4224 551b 2842 0a .$B$U.(B.
>
> Although musl iconv's output isn't optimal, it's still correct.
>
> From commit 7d509878b8, ("pretty.c: format string with truncate respects
> logOutputEncoding", 2014-05-21), we're encoding the message to utf-8
> first, then format it and convert the message to the actual output
> encoding on git commit --squash.
>
> Thus, t3900::test_commit_autosquash_flags is failing on musl libc.
>
> Reencode to utf-8 before arranging rebase's todo list.
OK, that makes sense.
> By doing this, we also remove a breakage introduced in the previous
> commit.
We'd usually say that a commit "introduced a breakage" if it was the
source of the bug. Perhaps:
...we also remove a breakage noticed by a test added in the previous
commit.
-Peff
