How to efficiently review a pull request that is full of linter changes?

Question

A lot of the changes are just lines have been reordered and within context, this isn't useful to me.Any tips to review a large pull request consisting of 1k lines changed all due to a new linter being applied.

gus_massa · Accepted Answer

It's a public repo or a PR inside the company where you work?Anyway, the solution is to ask nicely that the author rewrites the PR with the relevant changes, and then make another PR with the new linter. (Which linter to use, is a project-wide decision. Who is in charge of this?)

KolenCh · Answer

If there's a recipe to produce the change, ask for the recipe instead (and better yet, put it in the commit.) Then if you can reproduce that PR, and tests are passing, skim through it and see if nothing funny. Then it should be good to go.

zikohh · Answer

I'd like to add the most linters change things like line length and so on. However, this linter is changing the order of keys and values in a go struct (which I'd already formatted with go fmt), which makes it much harder to review than your typical line length change.

lantry · Answer

tldr: don't review linter changesRun the new linter on all the files. Don't make any other changes. Spot check a few places to make sure the linter doesn't majorly mess anything up. Make sure your automated tests still pass. Merge this change without reviewing every single line.Now that all your files are "clean", continue making changes and reviewing them like normal.

How to efficiently review a pull request that is full of linter changes?

A lot of the changes are just lines have been reordered and within context, this isn't useful to me.
Any tips to review a large pull request consisting of 1k lines changed all due to a new linter being applied.

It's a public repo or a PR inside the company where you work?
Anyway, the solution is to ask nicely that the author rewrites the PR with the relevant changes, and then make another PR with the new linter. (Which linter to use, is a project-wide decision. Who is in charge of this?)

If there's a recipe to produce the change, ask for the recipe instead (and better yet, put it in the commit.) Then if you can reproduce that PR, and tests are passing, skim through it and see if nothing funny. Then it should be good to go.

I'd like to add the most linters change things like line length and so on. However, this linter is changing the order of keys and values in a go struct (which I'd already formatted with go fmt), which makes it much harder to review than your typical line length change.