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

From: Marco Costalba <mcostalba@gmail.com>
Date: Dec 31, 2006, 15:43 UTC
Message-ID: <e5bfff550612310743t4ca1b017ubceddffafd06ac59@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0612311613180.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 11 quoted lines

>
> 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,

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 (I just remaind that's more then one year and an half that git-rev-list works in that way!) you may accept the concept of an option to show the additional optional header part. That's just what I'm asking, no more no less.

Show 10 quoted lines

>but by that time you should
> _already_ have stopped parsing! And the order is fixed already
> (parse_commit_buffer() relies on it).
>
> After all, you have an initial parsing for the purpose of organizing the
> commits, and you can have _another_ for the purpose of displaying the
> message (you can remember the offset where the first parsing stopped to
> accelerate the second). The latter parsing should be done individually,
> when displaying the commit.
>

The problem with your proposed algorithm is that you don't have _one_ commit but a sequence of commits to parse, so when you have parsed until the committer line you must need to know where the next commit starts, IOW you have to find the next '\0', that's what I was trying to expose in my previous e-mail postscriptum.

Thanks Marco