Thread: Request to add options to tools/git_changelog
I am again requesting the addition of options to tools/git_changelog so
I can more easily produce the release notes. I asked for this during
9.1 development and it was rejected. I am currently using my own
custom version of the tool, but have to merge community improvements
into the tool every year before I use it.
The attached patch gives you an idea of what I want to add. New options
are:
--details-after Show branch and author info after the commit description
--master-only Show commits made exclusively to the master branch
--oldest-first Show oldest commits first
I know of now to do this with a post-processing script.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment
On Wed, Apr 25, 2012 at 4:04 PM, Bruce Momjian <bruce@momjian.us> wrote: > I am again requesting the addition of options to tools/git_changelog so > I can more easily produce the release notes. I asked for this during > 9.1 development and it was rejected. I am currently using my own > custom version of the tool, but have to merge community improvements > into the tool every year before I use it. I surrender. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Bruce Momjian <bruce@momjian.us> writes:
> The attached patch gives you an idea of what I want to add.
This patch doesn't seem to be against HEAD?
> --details-after Show branch and author info after the commit description
I don't understand the point of that.
> --master-only Show commits made exclusively to the master branch
Agreed, this could be useful.
> --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?
regards, tom lane
On Wed, Apr 25, 2012 at 05:09:04PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > The attached patch gives you an idea of what I want to add. > > This patch doesn't seem to be against HEAD? Yes, if people approve, I will work on a current patch against HEAD. > > --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. > > --master-only Show commits made exclusively to the master branch > > Agreed, this could be useful. > > > --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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@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.
regards, tom lane
On Thu, Apr 26, 2012 at 01:26:16AM -0400, Tom Lane wrote: > Bruce Momjian <bruce@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. So you totally skipped over the concept that reading incremental patches is creation order is helpful. OK, obviously having options that actually help me write the release notes is not a priority for anyone else. I will continue to maintain my own version of the script, to keep the community script clean (and not useful for me). I just backpatched the changes since 9.1 and they applied cleanly to my version. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Apr 26, 2012 at 1:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 26, 2012 at 18:56, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Apr 26, 2012 at 1:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Bruce Momjian <bruce@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 haven't looked at the actual code to see if it's broken or not, but assuming it's not.... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Thu, Apr 26, 2012 at 06:59:18PM +0200, Magnus Hagander wrote: > On Thu, Apr 26, 2012 at 18:56, Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Apr 26, 2012 at 1:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.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.
regards, tom lane
On Thu, Apr 26, 2012 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.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. He can't be more than 33% I think, since I use it regularly as well. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 04/26/2012 02:54 PM, Robert Haas wrote: > On Thu, Apr 26, 2012 at 2:05 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Bruce Momjian<bruce@momjian.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. > He can't be more than 33% I think, since I use it regularly as well. :-) Perhaps he was using a weighted measure. ;-) cheers andrew
On Thu, Apr 26, 2012 at 02:05:23PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.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 ABCadd feature C to feature ABadd feature B to feature Aadd feature A More logical (oldest-first) is: add feature Aadd feature B to feature Aadd feature C to feature ABadd 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Apr 26, 2012 at 03:19:04PM -0400, Bruce Momjian wrote: > On Thu, Apr 26, 2012 at 02:05:23PM -0400, Tom Lane wrote: > > Bruce Momjian <bruce@momjian.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. Oh, one more thing. The contributor names appended to each release note item usually has to be listed A,B,C,D because A is usually the most significant contribution. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Apr 26, 2012 at 03:19:04PM -0400, Bruce Momjian wrote: > 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. Updated, attached patch applied. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Attachment
Bruce Momjian wrote: > I am again requesting the addition of options to tools/git_changelog so > I can more easily produce the release notes. I asked for this during > 9.1 development and it was rejected. I am currently using my own > custom version of the tool, but have to merge community improvements > into the tool every year before I use it. FYI in the general case of "I have to maintain a patch set": Now that PG is on git, there's a tool called Stacked Git that lets you use git's excellent merge capabilities to maintain patches. http://www.procode.org/stgit/ Jay
On Sun, Apr 29, 2012 at 02:06:48PM -0400, Jay Levitt wrote: > Bruce Momjian wrote: > >I am again requesting the addition of options to tools/git_changelog so > >I can more easily produce the release notes. I asked for this during > >9.1 development and it was rejected. I am currently using my own > >custom version of the tool, but have to merge community improvements > >into the tool every year before I use it. > > FYI in the general case of "I have to maintain a patch set": Now > that PG is on git, there's a tool called Stacked Git that lets you > use git's excellent merge capabilities to maintain patches. > > http://www.procode.org/stgit/ I am unclear what stgit does that can't be done with git branches? It mentions pushing and popping patches --- is that it? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +