|
|
Created:
7 years ago by enne (OOO) Modified:
6 years, 10 months ago CC:
chromium-reviews, cc-bugs_chromium.org, aelias_OOO_until_Jul13, ajuma, brianderson, ccameron, nduca, piman, shawnsingh, vmpstr, Ian Vollick, Vangelis Kokkevis Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
Descriptioncc: add git cl format presubmit warning
BUG=none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247888
Patch Set 1 #Patch Set 2 : old chunk mismatch #Messages
Total messages: 16 (0 generated)
This patch adds a presubmit warning when a patch to cc is not git cl formatted. Files outside of cc/ are not considered. Only the lines in the patch (and surrounding lines touching it) are formatted. If you're doing something horribly wrong like using svn, it will silently skip this step. Nobody else is using this presubmit step yet as it just got added. I realize 'git cl format'ing the world is probably contentious, so I'm CCing all cc/ owners here to let folks weigh in if they care. cc/ is largely autoformatted and I'm super tired of reminding people to format their patches during code review. This isn't something that I think the Chromium project as a whole wants, but I would like it for cc's neck of the woods and as an experiment of how it might work to show to other folks on the larger Chrome team. This depends on https://codereview.chromium.org/143903006/ to restrict the warning to only files changed in cc/.
I strongly endorse this product and/or service.
LGTM
On 2014/01/21 20:04:33, enne wrote: > This patch adds a presubmit warning when a patch to cc is not git cl formatted. > Files outside of cc/ are not considered. Only the lines in the patch (and > surrounding lines touching it) are formatted. If you're doing something > horribly wrong like using svn, it will silently skip this step. Nobody else is > using this presubmit step yet as it just got added. > > I realize 'git cl format'ing the world is probably contentious, so I'm CCing all > cc/ owners here to let folks weigh in if they care. > > cc/ is largely autoformatted and I'm super tired of reminding people to format > their patches during code review. This isn't something that I think the > Chromium project as a whole wants, but I would like it for cc's neck of the > woods and as an experiment of how it might work to show to other folks on the > larger Chrome team. > > This depends on https://codereview.chromium.org/143903006/ to restrict the > warning to only files changed in cc/. I like this but think the presubmit warning change should also include clang formatting of all code it affects as it will otherwise cause inconsistent style in files that are not correctly clang-formatted. And I'm afraid it will also make people include large style changes in their patches to avoid this warning. I'd rather see one or a couple of large style-only changes than having it mixed up with other real changes. If clang formatting all of cc/ in one patch is too disruptive, should we enable this on a per-file or per-directory bases?
On 2014/01/21 21:00:24, David Reveman wrote: > I like this but think the presubmit warning change should also include clang > formatting of all code it affects as it will otherwise cause inconsistent style > in files that are not correctly clang-formatted. And I'm afraid it will also > make people include large style changes in their patches to avoid this warning. > I'd rather see one or a couple of large style-only changes than having it mixed > up with other real changes. I don't think this is so bad. I clang-formatted every file in cc/ that referred to an OpenGL context recently and it wasn't very disruptive (IMO). > > If clang formatting all of cc/ in one patch is too disruptive, should we enable > this on a per-file or per-directory bases?
On 2014/01/21 21:00:24, David Reveman wrote: > I like this but think the presubmit warning change should also include clang > formatting of all code it affects as it will otherwise cause inconsistent style > in files that are not correctly clang-formatted. And I'm afraid it will also > make people include large style changes in their patches to avoid this warning. > I'd rather see one or a couple of large style-only changes than having it mixed > up with other real changes. I'm not sure what you mean by "should include clang formatting of all code it affects" as that's how I would describe how clang_format_diff.py works. If anything, this should lead to more consistent style when folks touch the same bit of code.
On Tue, Jan 21, 2014 at 4:09 PM, <[email protected]> wrote: > On 2014/01/21 21:00:24, David Reveman wrote: > > I like this but think the presubmit warning change should also include >> clang >> formatting of all code it affects as it will otherwise cause inconsistent >> > style > >> in files that are not correctly clang-formatted. And I'm afraid it will >> also >> make people include large style changes in their patches to avoid this >> > warning. > >> I'd rather see one or a couple of large style-only changes than having it >> > mixed > >> up with other real changes. >> > > I don't think this is so bad. I clang-formatted every file in cc/ that > referred > to an OpenGL context recently and it wasn't very disruptive (IMO). Whitespace changes inside of lines that are already being changed has been okay to review from my perspective. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
On 2014/01/21 21:11:09, enne wrote: > On 2014/01/21 21:00:24, David Reveman wrote: > > > I like this but think the presubmit warning change should also include clang > > formatting of all code it affects as it will otherwise cause inconsistent > style > > in files that are not correctly clang-formatted. And I'm afraid it will also > > make people include large style changes in their patches to avoid this > warning. > > I'd rather see one or a couple of large style-only changes than having it > mixed > > up with other real changes. > > I'm not sure what you mean by "should include clang formatting of all code it > affects" as that's how I would describe how clang_format_diff.py works. > > If anything, this should lead to more consistent style when folks touch the same > bit of code. I'm thinking of a per-file or a per-directory basis. This will only enforce clang-formatting of code that is changed, right? If a file has a somewhat different style now but at least does it consistently throughout the file this presubmit rule will cause us to land changes that make the file inconsistent. I find inconsistency the most annoying and would prefer if the whole file was clang-formatted prior to (or at the same time as) adding this presubmit rule. FWIW, I ran "git cl format" on one of my changes recently and it caused the indention of 200+ lines to change which made it impossible to see what I was actually changing in the patch. A patch that fails the formatting check is clearly better in this case but maybe these cases are rare enough that we can deal with them. I'm OK landing this as is and then leave it up to reviewers to decide if style-only changes to some file is required to avoid inconsistencies prior to landing some patch with real changes.
On 2014/01/21 22:40:18, David Reveman wrote: > On 2014/01/21 21:11:09, enne wrote: > > On 2014/01/21 21:00:24, David Reveman wrote: > > > > > I like this but think the presubmit warning change should also include clang > > > formatting of all code it affects as it will otherwise cause inconsistent > > style > > > in files that are not correctly clang-formatted. And I'm afraid it will also > > > make people include large style changes in their patches to avoid this > > warning. > > > I'd rather see one or a couple of large style-only changes than having it > > mixed > > > up with other real changes. > > > > I'm not sure what you mean by "should include clang formatting of all code it > > affects" as that's how I would describe how clang_format_diff.py works. > > > > If anything, this should lead to more consistent style when folks touch the > same > > bit of code. > > I'm thinking of a per-file or a per-directory basis. This will only enforce > clang-formatting of code that is changed, right? If a file has a somewhat > different style now but at least does it consistently throughout the file this > presubmit rule will cause us to land changes that make the file inconsistent. I > find inconsistency the most annoying and would prefer if the whole file was > clang-formatted prior to (or at the same time as) adding this presubmit rule. > > FWIW, I ran "git cl format" on one of my changes recently and it caused the > indention of 200+ lines to change which made it impossible to see what I was > actually changing in the patch. A patch that fails the formatting check is > clearly better in this case but maybe these cases are rare enough that we can > deal with them. > > I'm OK landing this as is and then leave it up to reviewers to decide if > style-only changes to some file is required to avoid inconsistencies prior to > landing some patch with real changes. FYI, I've now clang formatted all tile manager related code. Not sure it's a good idea to blindly clang format all of cc/ as I found a few cases where it needed some massaging to not completely butcher the code. I didn't make any manual formatting changes on top of "cl format" of course. That would defeat the purpose. I just added/moved comments and line breaks to have "cl format" produce a better result which is a bit annoying but I guess OK. Anyhow, I'd love to have this presubmit check for all changes to task_graph_runnner*, *raster_worker_pool* and tile_manger* now that that code is 100% clang formatted.
My plan is still to just enable this for all of cc and not for individual files. > I'm OK landing this as is and then leave it up to reviewers to decide if > style-only changes to some file is required to avoid inconsistencies prior to > landing some patch with real changes. These are exactly my feelings. This is a warning, not a presubmit error. If somebody is in the middle of a change that would be harder for a reviewer to review with formatting, then I think they should put up a formatting patch first and then their patch or do their patch first and follow up with formatting.
On 2014/01/23 22:04:33, enne wrote: > My plan is still to just enable this for all of cc and not for individual files. > > > I'm OK landing this as is and then leave it up to reviewers to decide if > > style-only changes to some file is required to avoid inconsistencies prior to > > landing some patch with real changes. > > These are exactly my feelings. > > This is a warning, not a presubmit error. If somebody is in the middle of a > change that would be harder for a reviewer to review with formatting, then I > think they should put up a formatting patch first and then their patch or do > their patch first and follow up with formatting. lgtm.
All prerequisites have landed. Everyone's had a week to respond, so I'm going to assume that silence is assent.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/100173010/60001
Retried try job too often on android_clang_dbg for step(s) slave_steps http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/100173010/60001
Message was sent while issue was closed.
Change committed as 247888 |