Re: [PATCH] commit: fix pretty-printing of messages with "\nencoding "

Jeff King [off-list ref] writes:

I wonder, though, if this function before or after is actually correct;
if there is no encoding header, we exit the function immediately. But if
we are changing the encoding from utf8 to a non-utf8 value, we
presumably should continue and actually insert the new encoding header.

The function is correct; the only reason it may recode to
non-utf8 is the user (or Porcelain such as qgit or gitk)
explicitly asked to do so -- from the final output they will get
the message in user-native encoding and without the extra
encoding header, thus we retain the backward compatible
behaviour before the re-encoding feature was introduced.

On Wed, Mar 28, 2007 at 03:10:07PM -0700, Junio C Hamano wrote:

The function is correct; the only reason it may recode to
non-utf8 is the user (or Porcelain such as qgit or gitk)
explicitly asked to do so -- from the final output they will get
the message in user-native encoding and without the extra
encoding header, thus we retain the backward compatible
behaviour before the re-encoding feature was introduced.

I see. But then why do we not simply strip the encoding header entirely,
and return in native format? Why do we insert a new encoding header
_only_ when there was one previously?

-Peff