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
