Skip site navigation (1) Skip section navigation (2)

Re: Request to add options to tools/git_changelog

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Request to add options to tools/git_changelog
Date: 2012-04-26 17:05:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Apr 26, 2012 at 06:59:18PM +0200, Magnus Hagander wrote:
> On Thu, Apr 26, 2012 at 18:56, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.
> +1 on the principle.

I agree adding rarely-used options to a tool doesn't make sense, but the
question is what percentage of the git_changelog userbase am I?  Also,
do we want to have me use a private tool to make release notes, that
will make it harder for someone else to do it in the future?

> I haven't looked at the actual code to see if it's broken or not, but
> assuming it's not....

I wrote it.  ;-)

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-04-26 17:18:10
Subject: Re: xReader, double-effort (was: Temporary tables under hot standby)
Previous:From: Magnus HaganderDate: 2012-04-26 16:59:18
Subject: Re: Request to add options to tools/git_changelog

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group