On 12/31/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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,
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.
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html