From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Request to add options to tools/git_changelog |
Date: | 2012-04-26 16:56:13 |
Message-ID: | CA+TgmoZPQiBoU9vxOAUb_tnzGwgXmw9MwLrcgw531hwrTgkgpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 26, 2012 at 1:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> On Wed, Apr 25, 2012 at 05:09:04PM -0400, Tom Lane wrote:
>>>> --details-after Show branch and author info after the commit description
>
>>> I don't understand the point of that.
>
>> The release notes have the author at the end of the text.
>
> So? The committer is very often not the author, so I'm not seeing that
> this helps much. Not to mention that the commit message is almost never
> directly usable as release note text, anyway.
>
>>>> --oldest-first Show oldest commits first
>
>>> This also seems rather useless in comparison to how much it complicates
>>> the code. We don't sort release note entries by commit date, so what's
>>> it matter?
>
>> It is very hard to read the commit messages newest-first because they
>> are often cummulative, and the order of items of equal weight is
>> oldest-first in the release notes.
>
> I'm unpersuaded here, too, not least because I have never heard this
> "oldest first" policy before, and it's certainly never been followed
> in any set of release notes I wrote.
Frankly, I think we should just let Bruce do what he wants, as long as
he doesn't break the tool for anybody else. It's not like the 20
lines of code are costing us anything.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-04-26 16:57:07 | Re: xReader, double-effort (was: Temporary tables under hot standby) |
Previous Message | Thom Brown | 2012-04-26 16:54:45 | Re: Assertion failure in indxpath.c |