Bug 28092

Summary: webkit-patch land will land changes even if the ChangeLog is wrong (and thus make the wrong commit message)
Product: WebKit Reporter: Adam Barth <abarth>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: aroben, cjerdonek, ddkilzer, eric, mrowe
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   

Adam Barth
Reported 2009-08-07 19:18:02 PDT
http://trac.webkit.org/changeset/46933 Not sure why. I don't remember anything unusual happening when I ran the tool.
Attachments
Mark Rowe (bdash)
Comment 2 2009-08-08 10:28:24 PDT
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?
Adam Barth
Comment 3 2009-08-08 10:38:55 PDT
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.
David Kilzer (:ddkilzer)
Comment 4 2009-08-08 11:08:29 PDT
(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.
Mark Rowe (bdash)
Comment 5 2009-08-08 11:13:12 PDT
(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.
David Kilzer (:ddkilzer)
Comment 6 2009-08-08 16:01:56 PDT
(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.
Eric Seidel (no email)
Comment 7 2009-11-10 11:41:37 PST
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.
Eric Seidel (no email)
Comment 8 2009-11-16 14:50:51 PST
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.
Eric Seidel (no email)
Comment 9 2010-04-01 23:19:24 PDT
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.
Eric Seidel (no email)
Comment 10 2010-04-01 23:21:52 PDT
*** Bug 33246 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.