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 / Tests | Assignee: | 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
http://trac.webkit.org/changeset/46933
Not sure why. I don't remember anything unusual happening when I ran the tool.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
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
Mark Rowe (bdash)
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
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)
(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)
(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)
(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)
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)
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)
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)
*** Bug 33246 has been marked as a duplicate of this bug. ***