From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Request to add options to tools/git_changelog |
Date: | 2012-04-26 19:19:04 |
Message-ID: | 20120426191904.GD23228@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 26, 2012 at 02:05:23PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > 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?
>
> 50% I think. The only thing that's really concerning me here is that
> the reverse-sort option seems likely to be bug-inducing, and I really
> don't grasp that it has real value. But whatever.
Well, newest first would show this:
add feature D to feature ABC
add feature C to feature AB
add feature B to feature A
add feature A
More logical (oldest-first) is:
add feature A
add feature B to feature A
add feature C to feature AB
add feature D to feature ABC
Also consider that A is usually the big, clear commit message, and B,C,D
are just minor adjustments with more brief commits, which might require
adjusting the release note item for feature A. When they are in
newest-first order, that is much harder.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-04-26 22:48:01 | Re: Future In-Core Replication |
Previous Message | Andrew Dunstan | 2012-04-26 19:08:54 | Re: Request to add options to tools/git_changelog |