the disadvantage of having tidy done every time is that PRs that make structural changes get very hard to review because of the whitespace noise. We should recommend that the tidy result be in a separate commit if we do this. (it also messes up the blamelists, but we hardly ever look at those, so not a big loss.) On Fri, Aug 28, 2015 at 8:32 AM, Harald Alvestrand <hta@google.com> wrote: > +rest of editors team > > I think "always run tidy" (or make the PR look as if it has been run) is a > good approach. > > > On Fri, Aug 28, 2015 at 12:07 AM, Martin Thomson <martin.thomson@gmail.com > > wrote: > >> I just started on a pull request again today and was >> shocked^Wunsurprised at the poor state the spec is in. I had an idea >> for stopping the rot that I thought that I would share. >> >> We already have a tidy configuration. Also, tidy returns an error >> status if it makes any changes when run. Therefore, simply run tidy >> as part of the travis checks, maybe with a nice error message >> explaining how to run tidy and clean up the PR. >> >> I think that's all that is needed from the tooling end, which should >> be simple enough to setup. I can generate a pull request if this is >> acceptable. >> >> n.b., I plan to do this for other specs that I edit anyway. >> >> As for outstanding pull requests that are in progress, after running >> tidy on the master branch, the fixup is relatively simple. >> >> git checkout -b prbranch2 origin/master >> git checkout prbranch webrtc.html >> make tidy >> git commit -C prbranch webrtc.html >> git checkout prbranch >> git reset --hard prbranch2 >> git branch -d prbranch2 >> git push -f mine prbranch >> >> (This just looks like a rebase and squash of the branch when it is done.) >> > >
Received on Friday, 28 August 2015 06:45:30 UTC