Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used

From: Constantine Plotnikov <constantine.plotnikov@gmail.com>
Date: Nov 12, 2008, 13:08 UTC
Message-ID: <85647ef50811120508j5074f892p1e2a95acfae8c0a8@mail.gmail.com>
In-Reply-To: <20081112112654.GA20640@coredump.intra.peff.net>

On Wed, Nov 12, 2008 at 2:26 PM, Jeff King <peff@peff.net> wrote:

Show 24 quoted lines

> [re-adding list to the cc]
>
> On Wed, Nov 12, 2008 at 02:11:46PM +0300, Constantine Plotnikov wrote:
>
>> > I don't actually use any encodings except UTF-8, so maybe there is some
>> > subtle reason not to do so that I don't understand, but I would have
>> > expected all of the format placeholders to respect any --encoding
>> > parameter.
>> >
>> Even if this is the bug, it would be better to leave the old behavior
>> for backward compatibility reasons and introduce new placeholders.
>> Currently tools have to decode messages according to the commit
>> encoding, and changing behavior of options will break these tools
>> that have implemented workaround for this problem.
>
> Are there such tools? I assumed they would have complained about this as
> a bug before writing their own encoding conversion tools. And this is,
> AFAIK, the first bug report.
>
> I don't mind playing it safe to avoid breaking other people's tools, but
> I'm also not excited about adding a second, "respect encoding" version
> of many placeholders (and it's not just %s and %b; I think you would
> need author and committer names and emails, too).
>

The reason for the request was that for IDE integration (I'm working on the IDEA plugin), we need to work with past versions of the git as well. However we could write that this is known git bug that will be fixed in some future version and just to show incorrect data in history view when non-UTF-8 encoding is used for a while. I hope that non-UTF-8 encoding for commits is indeed a rare case, so users will not complain much.

BTW for some reason --pretty=raw is affected by encoding option on the command line. And this is a bit surprising as from description of the raw format it looks like it should not be affected, because the re-encoded commit is not "the entire commit exactly as stored in the commit object". Possibly the man page should be updated to clarify this.

Regards, Constantine