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
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
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?