Tom Lane wrote: > I wrote: > > So I'd vote for having both --master-only and its inverse > > --ignore-master, but I'm not sure we need anything more general > > than that. > > On second thought ... one big problem with --master-only is that > it's useful only to the extent that you trust git_changelog to > have matched up master and back-branch commits. The tool is definitely > not perfect about that: sometimes related commits will not have > identical texts (this would be the committer's fault) or the timestamps > are not close enough (which can be git's fault, because of the way git > pull works). > > Personally, if I were preparing major-release notes, I don't think > I'd use a --master-only switch even if I had it. There aren't so many > back-branch commits that it's hard to get rid of them manually, and > having the full history in front of you makes it easier to be sure > you've deleted the matching HEAD commits too.
It is true that you might get a master-only commit and not see the back-branch commits that went with it. Usually such commits are either well known or mention the fact in the commit message. -- Bruce Momjian <br...@momjian.us> http://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
