Re: [PATCH v2 4/4] log: --author-date-order
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 20, 2013, 19:36 UTC
- Message-ID
- <7v61x8tw0a.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130610184918.GC2084@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 18 quoted lines
>> 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.