On Thu, Apr 26, 2012 at 06:59:18PM +0200, Magnus Hagander wrote: > On Thu, Apr 26, 2012 at 18:56, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Apr 26, 2012 at 1:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Bruce Momjian <br...@momjian.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
