I am also not a big fan of the automatic code formatting, when I am close to completing changes my cycle is closer to:
3. Build and Test
4. Push and PR
I iterate on the first three as I finish off a change, I have been caught in the past where a build step is making code changes which are now not in the commit. The reason I got into this testing was so that what I was building and testing represented the changes I was proposing.
Projects however that check the formatting would be detected in the build step.
First thing I usually do on every
project is running my bash script which replaces tabs with spaces
in selected file types and trims trailing spaces. It makes a huge
difference to GIT and potential conflicts.
Also if there's a development in more
parallel branches, it can be executed in all of them
independently, BUT it is not possible to do cherrypicks from the
history any more.... It is, but you have to fix conflicts.
I am not a fan of automatic formatting,
but in the case of the TCK everything is better than the current
Maybe instead of discussion we can
prepare some "prototype" first and then discuss if it is what we
What about using some tool such as
spotless  which can apply formatting
automatically and so we don't have to worry about
this while changing the code?
How would we run spotless tool against the master branch? I
see something called sbt on https://github.com/moznion/sbt-spotless,
is that the command line version of spotless tool that might
work against master branch?