Andres Freund <and...@anarazel.de> writes:
> On 2015-06-29 17:44:06 -0400, Tom Lane wrote:
>> Ah yes, didn't see that option. That's definitely better. I'd still vote
>> for restricting it to fit in an 80-column window though.
> I don't see the benefit of truncating away the end of the commit message
> - that'll just mean more manual work and harder to understand
> heading... It's also not like we're generally very religious about the
> line length in sgml?
Yeah we are. The only places you'll find where we aren't formatting to 77
or 78 columns or so are where it would require breaking SGML tags in weird
places. If we use this format without truncating the log lines then it'll
become practically impossible to edit release notes in a window less than
about 120 characters wide, and I for one will object to that. It doesn't
fit well in my usual screen layout. And it would be very wasteful of
screen space because even if you let regular text flow all the way to a
120-character margin, there are enough short lines like "<para>" that
there'd just be huge amounts of white space on your screen.
As for manual work to generate the format, we could fix that by getting
git_changelog to emit what we want. I'd think the best thing to start
from would be the summary lines interspersed with full commit messages
anyway; the raw output of git log is going to be near unusable for this
purpose, with or without truncation.
(There are two different things to worry about here. One is how you're
going to reverse-engineer the annotations into the release notes Bruce
already made. Even un-truncated first lines of commit messages will often
not be enough for matching up commits to those notes. But I'm thinking
more about how we do this in future release cycles, and for that, getting
git_changelog to help is clearly the ticket.)
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
