On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker <badalex@gmail.com> wrote:
> On Mon, Aug 16, 2010 at 18:48, Robert Haas <robertmhaas@gmail.com> wrote:
>> OK, try this. It takes about 14 seconds on my machine on my copy of
>> Magnus's test repository. Output looks like this:
>
> 14 seconds! That sound much too slow :-)
/me is very sorry master. Please beat your unworthy servant only
lightly... or alternatively, buy me a faster machine.
It should get a bit faster if we reduce the number of branches it
examines, which I assume is something we can do once we desupport 7.4
and 8.0. We could also add a --since argument which would doubtless
speed things up a lot, by truncating the history to, say, the last N
years. Also, it could possibly be rewritten to be faster still if it
started N simultaneous copies of git log simultaneously instead of in
sequence, and processed them incrementally rather than throwing them
into a giant hash table, which would also probably cut down memory
usage quite a bit. However, I'm not really inclined to spend a lot of
time on it unless it's actually bugging Tom.
Despite the fact that I wrote this basically in response to Tom's
complaint, I do think that it's generally useful, and will likely use
it myself from time to time. So I think we should consider checking
it into src/tools. Perhaps someone will feel an urge to hack on it
further. Another useful enhancement would be to allow it to run on
just those commits whose log message includes a certain string. This
would be useful for answering the question "which branches was this
patch committed to?". Of course, you can find that out using the
existing implementation also by searching the output, but this would
be more convenient (and faster).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company