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

I'm sorry to reply only now but I have problems with my internet connection, I am also not able to test Junio patches now.

Regarding qgit parsing 'bug' I would like to point out something that probably is not clear.

1) Parsing routine _must_ be able to sustain the loading of more then
40000 revisions in a couple of seconds, so must be very quick. A lot
of effort has been put to index the header info at maximum speed. Now
it takes about 300ms to parse the whole linux tree. You can have this
only if the header format is 'fixed enough', it means that you would
not expect whole new lines (new '\n' chars) to appear from nowhere in
header, with the exception of log message and parents info lines of
course.

2) I _have_ to rely on headers info because that's where I get data to
show the user, that's the whole point of calling git-rev-list with
--headers option.

3) The rule of double '\n\n' as an indicator of the start of log
message it's not only very slow, it's also broken in cases of no log,
see 7b7abfe3dd81d in Linux tree.

4) We are talking of keeping back compatibility, _fixing_ qgit does
not solves the issues with current qgit users.

So please I really would ask again to *do not print that encoding extra line if not requested to do so*

Thanks again Marco

P.S: One way to really speed up the indexing would be if git-rev-list prints at the beginning the length of the record, i.e. the distance from the next '\0' terminating point. I don't know if this info is already available to git-rev-list before to print the record or has to find it anyway, in the latter case there is no point in doing this. But in the former case it would be possible to avoid a costly find('\0'), starting from the beginning of log message. Log message is more then the half of all the record length so it would be possible to avoid a good amount of unuseful work because only the position of the next '\0' is needed during parsing, not the log message, that is retrieved and shown to the user only on demand, i.e. only for the selected revision.