Magnus Hagander <mag...@hagander.net> writes:
> On Mon, Aug 16, 2010 at 20:27, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Second, does git offer a way to collate matching log entries across
>> multiple branches?
> But what really is the usecase there?
Generating back-branch update release notes, mainly. We usually do that
first for the newest back branch, and then copy paste and edit as needed
into the older ones. It's a lot easier to see what needs to be adjusted
if you're looking at something like
2010-08-13 12:27 tgl
* src/backend/: catalog/namespace.c, utils/cache/plancache.c
(REL9_0_STABLE), catalog/namespace.c, utils/cache/plancache.c
(REL8_3_STABLE), catalog/namespace.c, utils/cache/plancache.c
(REL8_4_STABLE), catalog/namespace.c, utils/cache/plancache.c: Fix
Assert failure in PushOverrideSearchPath when trying to restore a
search path that specifies useTemp, but there is no active temp
schema in the current session. (This can happen if the path was
saved during a transaction that created a temp schema and was later
rolled back.) For existing callers it's sufficient to ignore the
useTemp flag in this case, though we might later want to offer an
option to create a fresh temp schema. So far as I can tell this is
just an Assert failure: in a non-assert build, the code would push
a zero onto the new search path, which is useless but not very
harmful. Per bug report from Heikki.
than half a dozen independent lists.
I've also found that answering questions about when some old patch got
added is easier from this format than I think it'd be if I had only
per-branch lists. I do have both the combined log history and
per-branch log histories at hand (from separate cvs2cl runs), but I find
that I hardly ever consult the latter.
It's not a showstopper, but if git can't do it I'll be disappointed.
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
