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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 1, 2007, 03:21 UTC
Message-ID: <7vodpja0u8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e5bfff550612310743t4ca1b017ubceddffafd06ac59@mail.gmail.com>

"Marco Costalba" <mcostalba@gmail.com> writes:

Show 12 quoted lines

> On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> Further, if you rely on parsing being super-fast, why not just parse
>> _only_ the header information that you actually need? The header still
>> consists of
>>
>>         - exactly one "tree",
>>         - an arbitrary amount of "parent" lines,
>>         - exactly one "author", and
>>         - exactly one "committer" line
>>
>> After that may come optional headers,

They are more like 'other' headers. Nobody said the set of headers are cast in stone forever. The only things parsers safely can assume are that the original four kinds come at the beginning in the above order, and there is a blank line that separates headers and the body.

> If you intorduce the concept of an 'optional header part' you
> logically and naturally _may_ also introduce the concept of disabling
> the display of _that_ optional header, or better, to keep back
> compatibility...

While I am somewhat sympathetic, and am willing to apologize for trying to advance the i18n support without enough advance warning, I think you already know what you are saying does not make much sense in the larger picture and as the longer term solution. Does any MUA ask the filesystem, POP3 server or IMAP server not to give X-* headers?

We could declare "headers are cast in stone and we will not enhance it in any way forever", and go back to my original hack to use hidden trailer, but I do not think it would solve anything. Porcelains that would try to take advantage of the trailer would now start assuming incorrectly that the set of trailers are cast in stone and will break when new information is added to the trailer, which would bring us back to exactly where we are now.

Having said that, I think what is in the current tip of 'master' is of much less impact for normal repositories than the one that bit you, in two aspects.

 * Your sample commit had "encoding UTF-8" header, presumably
   because the repository that the commit was created in had
   core.commitencoding set to "UTF-8".  The intent was not to
   add anything when the log message is UTF-8, but the earlier
   code was checking only for "utf-8".  With the current tip of
   master this should not happen anymore.

 * When the output encoding conversion is done successfully, the
   current tip of master drops "encoding" header from the
   output, so in your sample situation where the commit has
   (incorrectly) "encoding UTF-8" and your output encoding is
   also "UTF-8" (because either you have core.commitencoding set
   to it, or you do not have the configuration and let git fall
   back to its default which is UTF-8), you would not see the
   "encoding" header in the output from the rev-list.

The reason we did the latter, by the way, does not have anything to do with helping broken parsers. We drop the header after re-coding the log message into an encoding specified by the user (which is presumably different from what the commit was originally recorded in) because the encoding recorded on "encoding" header would not match the re-coded log message anymore.