Stephen Frost wrote:
> > Besides the sloppiness of back-patching in
> > that one macro and nothing else, this is a huge fraction of the patch
> > that's just *gone* in the 9.0 and 9.1 branches, and there's not so
> > much as a hint about it in the commit message, which is pretty
> > astonishing to me.
>
> Right, 9.0 and 9.1 don't have as detailed messages and so there wasn't
> as much to do in those older branches. I was well aware of that and I
> could have sworn that I included something in the commit messages..
> Looks like I did, but not in a way which was as clear as it should have
> been. Specifically, in those older branches, the commit message only
> talks about the functions which exist in those branches-
> BuildIndexValueDescription and ri_ReportViolation. The commit messages
> for 9.2 and beyond also reference ExecBuildSlotValueDescription, which
> is what you're getting at.
>
> In hindsight, I agree that doing just that wasn't sufficient and
> thinking on it now I realize that, while having different commit
> messages for each branch may make sense if you're only looking at that
> branch, it ends up being confusing for folks following the overall
> project as they likely look at just the subject of each commit and
> expect the contents for every branch to be the same. To that point,
> I'll try to be clearer when there's a difference in commit message for
> each branch, or simply include everything for every branch in an
> identical commit message across all of them.
FWIW using different commit messages for different branches is a
mistake. The implicit policy we have is that there is one message,
identical for all branches, that describe how the patch differs in each
branch whenever necessary. Note that the git_changelog output that
Robert pasted is not verbatim from the tool; what it actually prints is
three separate entries, one for each different message you used, which
is not what is supposed to occur.
I say this policy is implicit because I don't recall it being spelled
out anywhere, but since it's embodied in git_changelog's working
principle it's important we stick to it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
