Also, if you're using Eclipse to do the auto-format, please check for trailing white-space on otherwise empty javadoc lines.
If you automate this in some fashion outside of Eclipse (because other people may prefer other editors), this would be a useful script to add to a top-level dev-tools folder. On Wed, Jan 7, 2015 at 2:36 PM, David Medinets <[email protected]> wrote: > +1 > > Are you automating the process so that you can re-apply the same steps > in one year? > > On Wed, Jan 7, 2015 at 3:31 PM, Christopher <[email protected]> wrote: > > Can do. It's a bit more work for me, because I have to repeat the same > > actions over and over again, but if it helps history look a little > cleaner, > > i can do it, and just stick to -sours and repeat for the next branch.. > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > On Wed, Jan 7, 2015 at 3:25 PM, Mike Drob <[email protected]> wrote: > > > >> Please do not do formatting during merge conflict resolution, and make > >> those be separate commits. > >> > >> On Wed, Jan 7, 2015 at 2:23 PM, Josh Elser <[email protected]> > wrote: > >> > >> > ack'ed > >> > > >> > > >> > John Vines wrote: > >> > > >> >> +1 > >> >> > >> >> On Wed, Jan 7, 2015 at 3:12 PM, Christopher<[email protected]> > >> wrote: > >> >> > >> >> To make it easier to apply some minimal checkstyle rules for > >> >>> ACCUMULO-3451, > >> >>> I'm announcing my intentions to do a full, one-time, auto-format and > >> >>> organize imports on all our supported branches (1.5, 1.6, and > master) > >> to > >> >>> bring us up to some degree of compliance with our agreed-upon > >> formatting > >> >>> standards. > >> >>> > >> >>> Benefits: > >> >>> To have additional checks, in particular against javadoc problems > and > >> >>> other > >> >>> common trivial warnings in the build. > >> >>> To ensure less divergence from our agreed-upon formatting standards. > >> >>> Formatting first makes it much less tedious and easier on me to add > >> these > >> >>> checks to the build. > >> >>> > >> >>> Issues I've considered: > >> >>> I will deal with all the merge conflicts. > >> >>> I will ignore generated thrift code. > >> >>> Conflicts with new code in people's branches should be minimal (and > >> >>> easily > >> >>> resolved by formatting according to our standards). > >> >>> Regarding concerns about history tracking, in general, each format > >> change > >> >>> is small, but they are numerous. So, the impact on tracking history > >> >>> should > >> >>> be very minimal (you'll see things like a brace moved to the same > line > >> as > >> >>> the else statement it is associated with... stuff that won't > generally > >> >>> affect your ability to debug). > >> >>> I'll also do a "format only" commit, separately from any substantive > >> >>> changes regarding the rule changes, so the mass formatting change > will > >> >>> happen in one place, and it will also be easy to revert, if > absolutely > >> >>> necessary. > >> >>> > >> >>> I'll give this 24 hours (it can be reverted if somebody objects > after > >> >>> that). > >> >>> > >> >>> -- > >> >>> Christopher L Tubbs II > >> >>> http://gravatar.com/ctubbsii > >> >>> > >> >>> > >> >> > >> >
