"David E. Wheeler" <david@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: IgnoreRECHECK in CREATE OPERATOR CLASS, just throwing a NOTICE,
insteadofthrowing an error as 8.4 had been doing. The error interferedwith porting old database definitions
(particularlyforpg_migrator) without really buying any safety. Per bug #4817 andsubsequent 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:
Updaterelpagesand reltuples estimates in stand-alone ANALYZE, even ifthere's no analyzable attributes or indexes. We
alsoused to report0 live and dead tuples for such tables, which messed withautovacuum 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
