On Thu, Nov 07, 2019 at 02:48:58PM +0700, Danh Doan wrote:

quoted

# 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):

quoted

[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?

-Peff