So the steps I was performing were: 1) Eclipse format all java files 2) Eclipse organize all imports 3) Command-line sed to strip trailing whitespace (which gets those pesky "indented" empty javadoc lines) find . -name '*.java' -print0 | xargs -0 sed -i 's/ *$//' 4) Replace tab indents with spaces (these really surprised me, and I just manually fixed them) vim $(grep -R $'\t' . | cut -f 1 -d : | grep '\.java$' | sort | uniq) 5) Rebuild with -Pthrift, to ensure I don't touch generated files mvn package -DskipTests -Pthrift
#3 and #4 can't be easily done in Eclipse, but they are trivial sed/grep command lines. I wasn't planning on producing any script. I'd rather just point people to the sed/grep man pages, and the right menu options in Eclipse if they need to reproduce. After these steps, merged with -sours and repeated in each branch, the next two commits would simply be: add checkstyle rules to the pom, and modify remaining problems/errors/etc. to make rules pass. That part is easy, since I have a reasonable set of rules to work with. For Brian's concerns about -sours, I always check that the commit prior to the commits I intend to merge with -sours are already merged normally and conflicts resolved, so that the only commit merged with -sours is the one I intend (I actually kind of wish git had a built-in option/warning for that check... but I always do it anyway). -srecursive -Xours could still miss things, because it could improperly resolve some conflicts. In my case, they'd be equivalent, though. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jan 7, 2015 at 3:47 PM, Mike Drob <mad...@cloudera.com> wrote: > 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 <david.medin...@gmail.com> > 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 <ctubb...@apache.org> 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 <mad...@cloudera.com> 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 <josh.el...@gmail.com> > > wrote: > > >> > > >> > ack'ed > > >> > > > >> > > > >> > John Vines wrote: > > >> > > > >> >> +1 > > >> >> > > >> >> On Wed, Jan 7, 2015 at 3:12 PM, Christopher<ctubb...@apache.org> > > >> 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 > > >> >>> > > >> >>> > > >> >> > > >> > > >
