Re: [PATCH] Reencode committer info to utf-8 before formatting mail header

From: David Kågedal <davidk@lysator.liu.se>
Date: Jan 16, 2007, 12:43 UTC
Message-ID: <873b6b87lw.fsf@morpheus.local>
In-Reply-To: <Pine.LNX.4.63.0701161239590.22628@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 23 quoted lines

> Hi,
>
> On Mon, 15 Jan 2007, David Kågedal wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > On Fri, 12 Jan 2007, Junio C Hamano wrote:
>> >
>> >> Side note.  The previous patch does not help if your commit were
>> >> made in non UTF-8 with not too recent git; the code assumes that
>> >> commit messages without the new "encoding" headers are in UTF-8.
>> >
>> > Why not just use is_utf8() and warn, or error out, if the message is not 
>> > UTF-8? (I tend towards the erroring out, since this _is_ a new feature, 
>> > and gives undesired results with "old" commits.)
>> 
>> What do you mean? I have an old repository with latin1 commits without
>> any encoding markers.  I want to be able to use format-patch from that
>> and at least get a From: line with something readable.  You can't just
>> barf and say "This isn't UTF-8, go away".
>
> So what do you want to do instead? Just pretend that the unrecoded -- 
> Latin-1 encoded -- text is UTF-8? That's plain wrong.

That is what git did before I wrote my patch, so it obviously not what I want. I want to be able to tell git what encoding it is.

My patch reused the i18n.commitencoding configuration parameter for that, but Junio is probably right in that that is only meant for new commits, and an evironment variable makes more sense.

So just barfing on a commit that isn't utf-8 isn't a complete solution. But maybe there was some context to your comment above that I missed.

-- 
David Kågedal