Thread: Adding commit details to SGML release notes
On Tue, Jun 30, 2015 at 07:00:45PM +0000, Andres Freund wrote: > Improve 9.5 release notes. > > 1) Add sgml comments referencing commits. This is useful to search for > missing items etc. > > The comments containing the commit notes are an excerpt from: > git log --date=short \ > --pretty='format:%cd [%h] %<(8,trunc)%cN: %<(48,trunc)%s%n%n%w(,4,4)%b%n' \ > $(git merge-base origin/master upstream/REL9_4_STABLE)..origin/master To simplify the creation of the release note with the commit tag as an SGML comment, I think src/tools/git_changelog should be modified to output this string. The format "trunc" feature was added in git 1.8.3. Is that old enough for everyone? I am not going to need this until the 9.6 release notes. Should I add it or someone else? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Bruce Momjian wrote: > To simplify the creation of the release note with the commit tag as an > SGML comment, I think src/tools/git_changelog should be modified to > output this string. The format "trunc" feature was added in git 1.8.3. > Is that old enough for everyone? Hmm, that's pretty new actually, commit edca4152560522a431a51fc0a06147fc680b5b18 Author: Junio C Hamano <gitster@pobox.com> AuthorDate: Fri May 24 11:34:46 2013 -0700 CommitDate: Fri May 24 11:34:46 2013 -0700 Git 1.8.3 Since it's only needed by people preparing the release notes, I would guess it's okay --- evidently Tom was able to use it. Maybe an option is to use trunc when git 1.8.3 or newer is detected, and plain (no trunc) otherwise? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Bruce Momjian wrote:
>> To simplify the creation of the release note with the commit tag as an
>> SGML comment, I think src/tools/git_changelog should be modified to
>> output this string. The format "trunc" feature was added in git 1.8.3.
>> Is that old enough for everyone?
> Since it's only needed by people preparing the release notes, I would
> guess it's okay --- evidently Tom was able to use it.
Well, that's only because I'm running a hand-installed git rather than
what RHEL6 comes with.
> Maybe an option is to use trunc when git 1.8.3 or newer is detected, and
> plain (no trunc) otherwise?
Personally I find that truncated output to be pretty unreadable, and
would strongly object to changing git_changelog so that that was the only
possible format. However, I have no objection to making it an option
("git_changelog --short", or so), and that would dodge any concerns about
failing on git versions without the feature.
regards, tom lane
On Fri, Aug 28, 2015 at 05:32:38PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Bruce Momjian wrote:
> >> To simplify the creation of the release note with the commit tag as an
> >> SGML comment, I think src/tools/git_changelog should be modified to
> >> output this string. The format "trunc" feature was added in git 1.8.3.
> >> Is that old enough for everyone?
>
> > Since it's only needed by people preparing the release notes, I would
> > guess it's okay --- evidently Tom was able to use it.
>
> Well, that's only because I'm running a hand-installed git rather than
> what RHEL6 comes with.
Yes, I am running git 1.7.2.5 on Debian Squeeze, but I will be upgrading
in the next month, before the next major release notes are due, so I
would avoid the problem that way. :-)
> > Maybe an option is to use trunc when git 1.8.3 or newer is detected, and
> > plain (no trunc) otherwise?
>
> Personally I find that truncated output to be pretty unreadable, and
> would strongly object to changing git_changelog so that that was the only
> possible format. However, I have no objection to making it an option
> ("git_changelog --short", or so), and that would dodge any concerns about
> failing on git versions without the feature.
Well, my idea would be to change this git_changelog line:
Branch: master [01051a987] 2015-07-09 11:38:34 +0300
to output something in the new 'trunc' format, so we have it right next
to the release note text and the release notes easily get that comment.
If we _don't_ do that, how do you easily get those lines into the
release notes? I can't imagine how hard it was for Andres to add that
text to the 9.5 release notes:
http://www.postgresql.org/message-id/E1ZA0lx-0006FM-PU@gemulon.postgresql.org
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Aug 28, 2015 at 05:32:38PM -0400, Tom Lane wrote:
>> Personally I find that truncated output to be pretty unreadable, and
>> would strongly object to changing git_changelog so that that was the only
>> possible format. However, I have no objection to making it an option
>> ("git_changelog --short", or so), and that would dodge any concerns about
>> failing on git versions without the feature.
> Well, my idea would be to change this git_changelog line:
> Branch: master [01051a987] 2015-07-09 11:38:34 +0300
> to output something in the new 'trunc' format, so we have it right next
> to the release note text and the release notes easily get that comment.
Right, I'm merely saying that I want the current format by default, and
the trunc format only with a command-line option.
regards, tom lane
On 2015-08-28 17:49:35 -0400, Bruce Momjian wrote: > If we _don't_ do that, how do you easily get those lines into the > release notes? I can't imagine how hard it was for Andres to add that > text to the 9.5 release notes: Formatting the log wasn't the hard part, that was finding out which item in the release notes corresponds to which commits. Sometimes that's not that easy to see. For the formatting I had an emacs macro. Greetings, Andres Freund
On Sat, Aug 29, 2015 at 12:23:30AM +0200, Andres Freund wrote: > On 2015-08-28 17:49:35 -0400, Bruce Momjian wrote: > > If we _don't_ do that, how do you easily get those lines into the > > release notes? I can't imagine how hard it was for Andres to add that > > text to the 9.5 release notes: > > Formatting the log wasn't the hard part, that was finding out which item > in the release notes corresponds to which commits. Sometimes that's not > that easy to see. For the formatting I had an emacs macro. Right, the formatting is easy with any good editor, but having the text there as you are writing the release notes is a huge time-saver, and if we want that text, it should be present in the git_changelog output when creating those release notes. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +