On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker <bada...@gmail.com> wrote: > On Mon, Aug 16, 2010 at 18:48, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers