Summary: | EWS provides misleading information for not applyable patches | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> | ||||
Component: | Tools / Tests | Assignee: | Csaba Osztrogonác <ossy> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, commit-queue, dbates, ddkilzer, ossy, rniwa | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Csaba Osztrogonác
2015-05-22 04:54:32 PDT
That would be a very recent regression. What changed? This just worked correctly in <https://webkit-queues.appspot.com/patch/253595> - windows bubble is red. Style checker is clearly wrong, but how did you determine that other bubbles in <https://bugs.webkit.org/show_bug.cgi?id=145247> are green for a wrong reason? (In reply to comment #3) > Style checker is clearly wrong, but how did you determine that other bubbles > in <https://bugs.webkit.org/show_bug.cgi?id=145247> are green for a wrong > reason? The problem is that webkit-patch tries to apply the patch, but there is no appliable diff in the patch. In this case the green GTK/Mac/EFL bubbles mean that the trunk is buildable, nothing else. It is very misleading. I think the best fix would be to make svn-apply not to return 0 in this case. Created attachment 253994 [details]
Patch
To summarize, this happens when a patch tries to update non-existent files. When a patch doesn't apply to existent files, we already get the correct behavior. Given that, I suspect that a more targeted fix is possible. However, adding a catch-all like this is fine too. Comment on attachment 253994 [details] Patch Clearing flags on attachment: 253994 Committed r185062: <http://trac.webkit.org/changeset/185062> All reviewed patches have been landed. Closing bug. |