Re: Managing multiple branches in git

"David E. Wheeler" <david(at)kineticode(dot)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