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

From: Jeff King <peff@peff.net>
Date: Nov 7, 2019, 06:32 UTC
Message-ID: <20191107063223.GF6431@sigill.intra.peff.net>
In-Reply-To: <36796e2b679cd8b2d341058e775db401f9abcef7.1573094789.git.congdanhqx@gmail.com>

On Thu, Nov 07, 2019 at 09:56:19AM +0700, Doan Tran Cong Danh wrote:

Show 9 quoted lines

> The message file will be used as commit message for the
> git-{am,rebase} --continue.
>
> [...]
>  	strbuf_addf(&buf, "%s/message", get_dir(opts));
>  	if (!file_exists(buf.buf)) {
> -		const char *commit_buffer = get_commit_buffer(commit, NULL);
> +		const char *encoding = get_commit_output_encoding();
> +		const char *commit_buffer = logmsg_reencode(commit, NULL, encoding);

That makes sense, though it's hard to understand the flow of this data through multiple sequencer invocations. I _think_ this would be fixing a case like this:

-- >8 -- git init repo cd repo

# some commits to build off of echo base >file git add file git commit -m base

echo side >file git add file git commit -m side

# now make a commit in iso8859-1 git checkout -b side HEAD^ echo iso8859-1 >file git add file iconv -f utf8 -t iso8859-1 <<-\EOF | súbject

bödy EOF git -c i18n.commitEncoding=iso8859-1 commit -F -

# and rebase it with the merge strategy, which will fail; # now .git/rebase-merge/message has iso8859-1 in it git rebase -m master

# 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", or if it's in one of the other files. But it's not clear to me how this "message" file is being used.

-Peff