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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
