Robert Haas <robertmhaas@gmail.com> writes:
> No, he wants to exclude things that were back-patched. But I agree
> it's kind of grotty. Imagine you are preparing release notes for a
> minor release. Now you will want all the back-branch commits, but not
> the ones that were only committed to master. I think rather than
> inserting piecemeal hacks like this, we should try to be a bit more
> generic, something like -x branchname to exclude any commit that
> touches the named branch, and -o branchname to restrict the output to
> commits that touch ONLY the named branch, or something along those
> lines.
OK, but if we're going to try to design this more generally, let's keep
in mind what the *actual* workflow is. We don't prepare release notes
for one back branch in isolation. Every update release for lo these many
years has been for multiple back branches concurrently, with usually
mostly the same patches applied to all of them. I shouldn't speak for
Bruce, but when I do it, I make one set of release notes covering all
the back-patched patches. After I'm happy with the presentation of
that, I copy it into each back branch's SGML section and strip out any
items not relevant to that branch. The output of git_changelog is
already pretty well suited to that workflow, although it would be handy
to have a switch to exclude master-only commits.
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.
regards, tom lane
