Jeff King <peff@xxxxxxxx> writes:
>> Or we could extend parse_commit() API to take an optional commit
>> info slab to store not just author date but other non-essential
>> stuff like people's names, and we arrange that extended API to be
>> triggered when we know --author-date-order is in effect?
>
> I like the latter option. It takes a non-trivial amount of time to load
> the commits from disk, and now we are potentially doing it 2 or 3 times
> for a run (once to parse, once to get the author info for topo-sort, and
> possibly later to show it if --pretty is given; though I did not check
> and maybe we turn off save_commit_buffer with --pretty). It would be
> nice to have an extended parse_object that handled that. I'm not sure of
> the interface. Maybe variadic with pairs of type/slab, like:
>
> parse_commit_extended(commit,
> PARSE_COMMIT_AUTHORDATE, &authordate_slab,
> PARSE_COMMIT_DONE);
>
> ?
What I had in mind actually was a custom slab tailored for each
caller that is an array of struct. If the caller is interested in
authordate and authorname, instead of populating two separate
authordate_slab and authorname_slab, the caller declares a
struct {
unsigned long date;
char name[FLEX_ARRAY];
} author_info;
prepares author_info_slab, and use your commit_parser API to fill
them.
--
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