"David E. Wheeler" <da...@kineticode.com> writes: > On Jun 2, 2009, at 3:11 PM, Tom Lane wrote: >> Maybe that special log tool Andrew was >> speculating about would take the form of a program to aggregate the >> change histories of several repositories.
> You mean so that such patches in back branches show up in the the > history of master? No, just so they're available in the actual text we consult when we are preparing release notes or wondering when some bug was fixed. I was not aware that so few people are familiar with cvs2cl. Perhaps it would help to show some examples of its output. HEAD-only patch: 2009-05-27 16:42 tgl * src/: backend/parser/gram.y, bin/pg_dump/pg_dump.c: Ignore RECHECK in CREATE OPERATOR CLASS, just throwing a NOTICE, instead of throwing an error as 8.4 had been doing. The error interfered with porting old database definitions (particularly for pg_migrator) without really buying any safety. Per bug #4817 and subsequent discussion. Backpatched fix: 2009-05-19 04:30 heikki * src/backend/commands/: analyze.c (REL8_1_STABLE), analyze.c (REL8_3_STABLE), analyze.c (REL8_2_STABLE), analyze.c: Update relpages and reltuples estimates in stand-alone ANALYZE, even if there's no analyzable attributes or indexes. We also used to report 0 live and dead tuples for such tables, which messed with autovacuum threshold calculations. This fixes bug #4812 reported by George Su. Backpatch back to 8.1. A back-branch-only fix would look the same except for not having any unannotated filenames. I'm too lazy to go trolling for one just now. It's also possible to get it to produce histories that include only the patches on particular branches. I'm not by any means wedded to the details of this printout format; it's kinda ugly in fact. The point that I want to make is that I can look at the commit history in a summary form that just shows me the commit message, date/time/committer, affected file(s) and branch(es), and is not picky about whether the changes were byte-for-byte the same in each branch (because they hardly ever are). The project's entire commit history for, hm, probably the last ten years is specifically designed to be able to get this type of report out of the repository, and we're going to be pretty seriously unhappy if git is not able to replicate this functionality. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers