style checker says the following: Total errors found: 0 in 0 files If any of these errors are false positives, please file a bug against check-webkit-style. ---- and other bubbles are green, because they didn't apply anything for example: https://bugs.webkit.org/show_bug.cgi?id=145247 https://bugs.webkit.org/show_bug.cgi?id=126433 https://bugs.webkit.org/show_bug.cgi?id=138332 https://bugs.webkit.org/show_bug.cgi?id=126022 https://bugs.webkit.org/show_bug.cgi?id=70610
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.