Re: [PATCH v4 8/8] sequencer: reencode commit message for am/rebase --show-current-patch

> On Thu, Nov 07, 2019 at 02:48:58PM +0700, Danh Doan wrote:
> 
> > > # and if we resolve and commit, presumably we'd get a broken commit,
> > > # with iso8859-1 and no encoding header
> > > echo resolved >file
> > > git add file
> > > GIT_EDITOR=: git rebase --continue
> > > -- 8< --
> > > 
> > > But somehow it all seems to work. The resulting commit has real utf8 in
> > > it. I'm not sure if we pull it from the original commit via "commit -c",
> > 
> > Yes, somehow it worked. But, without this patch, git also warns:
> > 
> >     % GIT_EDITOR=: git rebase --continue
> >     Warning: commit message did not conform to UTF-8.
> >     You may want to amend it after fixing the message, or set the config
> >     variable i18n.commitencoding to the encoding your project uses.
> > 
> > Checking with strace (on glibc, musl strace can't trace execve):
> > 
> > > [pid 12848] execve("/home/danh/workspace/git/git", ["/home/danh/workspace/git/git", "commit", "-n", "-F", ".git/rebase-merge/message", "-e", "--allow-empty"], 0x558fb02e8240 /* 51 vars */) = 0
> > 
> > Turn out, it's because of: commit.c::verify_utf8
> > 
> >     /*
> >      * This verifies that the buffer is in proper utf8 format.
> >      *
> >      * If it isn't, it assumes any non-utf8 characters are Latin1,
> >      * and does the conversion.
> >      */
> >     static int verify_utf8(struct strbuf *buf)
> > 
> > Hence, your test is just pure luck (because it's in latin1).
> 
> Ah, thanks for resolving that mystery. Is it worth turning the scenario
> above into a test?