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

"Marco Costalba" [off-list ref] writes:

On 1/1/07, Junio C Hamano [off-list ref] wrote:

quoted

"Marco Costalba" [off-list ref] writes:

quoted

On 12/31/06, Johannes Schindelin [off-list ref] wrote:

quoted

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'

I think that is correct, except that rev-list does not even care
the distinction between log title and log message.

I do not think of a reason to change the order of the first four
offhand, so while it might be prudent to prepare the code to
accept them in any order if it is not too much trouble from
purist point of view, I do not think it is necessary in practice
and you should be able to depend on the order in which they
appear.  I do not think it would hurt anybody if we right now
declared that other extra headers people have talked about (such
as "notes") should always come after the first four.