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.
regards, tom lane