Re: [HACKERS] Request to add options to tools/git_changelog

2012-05-02 Thread Bruce Momjian
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  br...@momjian.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-29 Thread Jay Levitt

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-27 Thread Bruce Momjian
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 br...@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  br...@momjian.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-27 Thread Bruce Momjian
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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
*** /pg/tools/git_changelog	2012-01-01 17:48:55.0 -0500
--- /rtmp/pggitlog	2012-04-27 17:06:19.0 -0400
***
*** 40,48 
  # Might want to make this parameter user-settable.
  my $timestamp_slop = 600;
  
  my $post_date = 0;
  my $since;
! Getopt::Long::GetOptions('post-date' = \$post_date,
   'since=s' = \$since) || usage();
  usage() if @ARGV;
  
--- 40,57 
  # Might want to make this parameter user-settable.
  my $timestamp_slop = 600;
  
+ my $details_after = 0;
  my $post_date = 0;
+ my $master_only = 0;
+ my $oldest_first = 0;
  my $since;
! my @output_buffer;
! my $output_line = '';
! 
! Getopt::Long::GetOptions('details-after' = \$details_after,
! 			 'master-only' = \$master_only,
! 			 'post-date' = \$post_date,
! 			 'oldest-first' = \$oldest_first,
   'since=s' = \$since) || usage();
  usage() if @ARGV;
  
***
*** 179,195 
  	last if !defined $best_branch;
  	my $winner =
  		$all_commits_by_branch{$best_branch}-[$position{$best_branch}];
! 	printf Author: %s\n, $winner-{'author'};
! 	foreach my $c (@{$winner-{'commits'}}) {
! 	printf Branch: %s, $c-{'branch'};
! 	if (defined $c-{'last_tag'}) {
! 		printf  Release: %s, $c-{'last_tag'};
! 	}
! 	printf  [%s] %s\n, substr($c-{'commit'}, 0, 9), $c-{'date'};
  	}
! 	print \n;
! 	print $winner-{'message'};
! 	print \n;
  	$winner-{'done'} = 1;
  	for my $branch (@BRANCHES) {
  		my $leader = $all_commits_by_branch{$branch}-[$position{$branch}];
--- 188,204 
  	last if !defined $best_branch;
  	my $winner =
  		$all_commits_by_branch{$best_branch}-[$position{$best_branch}];
! 
! 	# check for master-only
! 	if (! $master_only || ($winner-{'commits'}[0]-{'branch'} eq 'master' 
! 	@{$winner-{'commits'}} == 1)) {
! 		output_details($winner) if (! $details_after);
! 		output_str(%s, $winner-{'message'} . \n);
! 		output_details($winner) if ($details_after);
! 		unshift(@output_buffer, $output_line) if ($oldest_first);
! 		$output_line = '';
  	}
! 
  	$winner-{'done'} = 1;
  	for my $branch (@BRANCHES) {
  		my $leader = $all_commits_by_branch{$branch}-[$position{$branch}];
***
*** 200,205 
--- 209,216 
  	}
  }
  
+ print @output_buffer if ($oldest_first);
+ 
  sub push_commit {
  	my ($c) = @_;
  	my $ht = hash_commit($c);
***
*** 258,268 
  	return $gm - $tzoffset;
  }
  
  sub usage {
  	print STDERR EOM;
! Usage: git_changelog [--post-date/-p] [--since=SINCE]
! --post-date Show branches made after a commit occurred
! --since Print only commits dated since SINCE
  EOM
  	exit 1;
  }
--- 269,306 
  	return $gm - $tzoffset;
  }
  
+ sub output_str {
+ 	($oldest_first) ? ($output_line .= sprintf(shift, @_)) : printf(@_);
+ }
+ 
+ sub output_details {
+ 	my $item = shift;
+ 
+ 	if ($details_after) {
+ 		$item-{'author'} =~ m{^(.*?)\s*[^]*$};
+ 		# output only author name, not email address
+ 		output_str((%s)\n, $1);
+ 	} else {
+ 		output_str(Author: %s\n, $item-{'author'});
+ 	}
+ 	foreach my $c (@{$item-{'commits'}}) {
+ 	output_str(Branch: %s , $c-{'branch'}) if (! $master_only);
+ 	if (defined $c-{'last_tag'}) {
+ 		output_str(Release: %s , $c-{'last_tag'});
+ 	}
+ 	output_str([%s] %s\n, substr($c-{'commit'}, 0, 9), $c-{'date'});
+ 	}
+ 	output_str(\n);
+ }
+ 
  sub usage {
  	print STDERR EOM;
! Usage: git_changelog [--details-after/-d] [--master-only/-m] [--oldest-first/-o] [--post-date/-p] [--since=SINCE]
! --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
! --post-date Show branches made after a commit occurred
! --since Print only commits dated since SINCE
  EOM
  	exit 1;
  }

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Bruce Momjian
On Thu, Apr 26, 2012 at 01:26:16AM -0400, Tom Lane 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.

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  br...@momjian.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Robert Haas
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Magnus Hagander
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 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/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Bruce Momjian
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.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Tom Lane
Bruce Momjian br...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Robert Haas
On Thu, Apr 26, 2012 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Bruce Momjian br...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Andrew Dunstan



On 04/26/2012 02:54 PM, Robert Haas wrote:

On Thu, Apr 26, 2012 at 2:05 PM, Tom Lanet...@sss.pgh.pa.us  wrote:

Bruce Momjianbr...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-26 Thread Bruce Momjian
On Thu, Apr 26, 2012 at 02:05:23PM -0400, Tom Lane wrote:
 Bruce Momjian br...@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.

-- 
  Bruce Momjian  br...@momjian.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-25 Thread Robert Haas
On Wed, Apr 25, 2012 at 4:04 PM, Bruce Momjian br...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-25 Thread Tom Lane
Bruce Momjian br...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-25 Thread Bruce Momjian
On Wed, Apr 25, 2012 at 05:09:04PM -0400, Tom Lane wrote:
 Bruce Momjian br...@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  br...@momjian.ushttp://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


Re: [HACKERS] Request to add options to tools/git_changelog

2012-04-25 Thread Tom Lane
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.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers