Re: Patch to git_changelog for release note creation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to git_changelog for release note creation
Date: 2011-03-15 14:57:07
Message-ID: 201103151457.p2FEv7r25534@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> I wrote:
> > So I'd vote for having both --master-only and its inverse
> > --ignore-master, but I'm not sure we need anything more general
> > than that.
>
> On second thought ... one big problem with --master-only is that
> it's useful only to the extent that you trust git_changelog to
> have matched up master and back-branch commits. The tool is definitely
> not perfect about that: sometimes related commits will not have
> identical texts (this would be the committer's fault) or the timestamps
> are not close enough (which can be git's fault, because of the way git
> pull works).
>
> Personally, if I were preparing major-release notes, I don't think
> I'd use a --master-only switch even if I had it. There aren't so many
> back-branch commits that it's hard to get rid of them manually, and
> having the full history in front of you makes it easier to be sure
> you've deleted the matching HEAD commits too.

It is true that you might get a master-only commit and not see the
back-branch commits that went with it. Usually such commits are either
well known or mention the fact in the commit message.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-15 14:58:24 Re: dependency between numbers keywords and parser speed
Previous Message Alvaro Herrera 2011-03-15 14:53:49 Re: Macros for time magic values