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

> On 1/1/07, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > 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.
>>
>
> I'm cooking the qgit parser fix, please confirm the following
> assumption is correct:
>
> 	When git-rev-list is called with --header option, after the first
> 	line with the commit sha, the following information is produced
> 	
> 	- one line with "tree"
> 	- an arbitrary amount of "parent" lines
> 	- one line with "author"
> 	- one line with "committer"
> 	- zero or more *non blank* lines with other info, as the encoding
> 	- one blank line
> 	- zero or one line with log title
> 	- zero or more lines with log message
> 	- a terminating '\0'