This is a dupe of one of:
https://bugs.webkit.org/show_bug.cgi?id=26730
https://bugs.webkit.org/show_bug.cgi?id=26865
https://bugs.webkit.org/show_bug.cgi?id=27355

And in <http://trac.webkit.org/changeset/46928>.  Can we get this fixed so we don't have bogus commit messages sprinkled throughout the SVN history?

Eric said on IRC:

eseidel: bdash: either svn-apply or bugzilla-tool need to be taught to run resolve-ChangeLogs -f on every ChangeLog

We can certainly try that and see if it helps.

(In reply to comment #2)
> And in <http://trac.webkit.org/changeset/46928>.  Can we get this fixed so we
> don't have bogus commit messages sprinkled throughout the SVN history?

I've seen this happen with prepare-ChangeLog commits as well.

(In reply to comment #3)
> eseidel: bdash: either svn-apply or bugzilla-tool need to be taught to run
> resolve-ChangeLogs -f on every ChangeLog
> 
> We can certainly try that and see if it helps.

I would suggest adding an -a|--all swtich to resolve-ChangeLogs (rather than changing the behavior of the -f switch) to make it attempt to fix up every ChangeLog.

The -f switch has special behavior that rewrites changelogs on a range of git commits using git-filter-branch --tree-filter.

(In reply to comment #4)
> (In reply to comment #2)
> > And in <http://trac.webkit.org/changeset/46928>.  Can we get this fixed so we
> > don't have bogus commit messages sprinkled throughout the SVN history?
> 
> I've seen this happen with prepare-ChangeLog commits as well.

I'm not sure what you mean.  In this case it seems that the patch author put the ChangeLog at some bizarre location within the file: <https://bugs.webkit.org/attachment.cgi?id=34264&action=prettypatch>.  Rather than fixing it up, bugzilla-tool left it in that location and took the first ChangeLog entry as the commit message.  I don't think any of our existing scripts will automagically fix this.

In <http://trac.webkit.org/changeset/46933> it just appears to be confused about where one ChangeLog entry ends and the second begins.

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > And in <http://trac.webkit.org/changeset/46928>.  Can we get this fixed so we
> > > don't have bogus commit messages sprinkled throughout the SVN history?
> > 
> > I've seen this happen with prepare-ChangeLog commits as well.
> 
> I'm not sure what you mean.

Sorry, I should have said:  I've seen commit-log-editor pick the wrong changelog entries, but it was probably due to the ChangeLog entry being merged into the wrong location.

I believe these were all caused by bug 30683, which is now resolved.  We can keep this open to track adding some sort of pre-commit hook for validating ChangeLog entries (see bug 28291) if you like.  Otherwise I think we can close this.  Certainly I'm un-aware of any bad ChangeLog entries from bugzilla-tool or the commit-queue since the ones mentioned in this bug.

Looks like land-diff was at fault in all of these commits.  I was initially confused, thinking that this bug was accusing land-patches, which we've never seen this behavior with.  http://trac.webkit.org/changeset/51033 was our most recent victim of this behavior.

I guess land-diff will need to resolve-ChangeLogs.  I'll try to look into it this week.

webkit-patch land will validate that the Reviewer is correct now.  However it doesn't yet validate that the ChangeLog entry being added is the top-most one.  That's still on our list to do.  It requires webkit-patch to have a bit of diff-parsing knowledge, which it should be able to get from the style package (check-webkit-style) which already has some minimal diff parsing.

*** Bug 33246 has been marked as a duplicate of this bug. ***