Re: Possible regression in git-rev-list --header

From: Junio C Hamano <junkio@cox.net>
Date: Dec 31, 2006, 01:45 UTC
Message-ID: <7v64bsj0s4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0612310211300.25709@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

> On Sat, 30 Dec 2006, Junio C Hamano wrote:
>
>> Another thing.  I think it would make sense to remove "encoding" header 
>> after pretty_print_commit successfully re-codes the buffer.  An 
>> alternative is to rewrite "encoding" header to show which encoding the 
>> log now uses (and omit it if it is UTF-8).
>
> I think it would be wrong. Sure, the output may be encoded differently, 
> but the _original_ commit was not. And this is the information I want 
> to see when I look at the raw commit.

When you want to see the raw commit, you would not ask for it to re-code, so "removal after successfully re-codes" would not kick in (if you _really_ want to look at the raw commit, I guess cat-file can help, but let's not go there). Re-coding the message but still showing what the original encoding was does not sound making much sense to me.

I've pushed this out after a small rework.

The rule is:

 - if you ask for re-coding (either by i18n.* configuration or
   an explicit --encoding option from the command line), and if
   re-coding successfully does its job, you do not see
   "encoding" header;

 - if the buffer cannot successfully be re-coded, no re-coding
   is done, and the caller can inspect "encoding" header.

 - if you do not ask for re-coding, "encoding" header is left as
   is, so is the commit log message.  The caller can deal with
   any re-coding itself.