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

From: Marco Costalba <mcostalba@gmail.com>
Date: Jan 3, 2007, 09:21 UTC
Message-ID: <e5bfff550701030121n700fab25x63278457c884a3f7@mail.gmail.com>
In-Reply-To: <7vodpja0u8.fsf@assigned-by-dhcp.cox.net>

On 1/1/07, Junio C Hamano <junkio@cox.net> wrote:

Show 21 quoted lines

> "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'

Thanks Marco