On Thu, Nov 07, 2019 at 09:56:17AM +0700, Doan Tran Cong Danh wrote: > On fixup/squash-ing rebase, git will create new commit in > i18n.commitencoding, reencode the commit message to that said encode. That makes sense (and I agree this is logically distinct from the previous ones, which were about _showing_ commits, not generating them). I wondered who is responsible for setting the "encoding" header in the resulting object. It looks like we just call out to a separate "git commit", feeding it some content we wrote out to a file. So before this patch, I think we probably are writing out "encoding iso8859-1" or whatever in the commit object, but actually outputting whatever the original commit happened to have in it. So your approach here is right: we just need to make sure what we write out for git-commit to read back in is in i18n.commitEncoding. > diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh > index e8ce5323ee..521d7bb927 100755 > --- a/t/t3900-i18n-commit.sh > +++ b/t/t3900-i18n-commit.sh > @@ -209,6 +209,13 @@ test_commit_autosquash_multi_encoding () { > old=$2 > new=$3 > msg=$4 > + squash_msg= > + if test $flag = squash; then > + squash_msg=' > + subject="squash! $(head -1 expect)" && > + printf "\n%s\n" "$subject" >> expect && > + ' > + fi Now what's going on here? This is a snippet of code we man to evaluate later: > - test_line_count = 3 actual > + test_line_count = 3 actual && > + iconv -f '$old' -t utf-8 "$TEST_DIRECTORY/t3900/'$msg'" >expect && > + '"$squash_msg"' I assume this is part of the same confusion that caused the single-quotes in the earlier patch. You can just include those lines inline in the quoted test snippet. -Peff