[zanata-devel] The great Zanata reformat of 2013

[Sean Flanigan]

On 2013-09-27 18:17, Sean Flanigan wrote:
> Hi All,
> 
> I have just committed the reformat for zanata-server, the last of the
> main Zanata repos.  I already formatted parent, api, common and client
> earlier.
> 
> All the formatter profiles I used can be found in the zanata-parent repo:
> * eclipse-code-formatter*.xml: Eclipse code formatter profiles for Java
> and JavaScript.  NB: these can (and should) be used with the IntelliJ
> plugin too: http://plugins.jetbrains.com/plugin/?idea&id=6546
> * intellij-code-style-settings.jar: IntelliJ code style settings for
> other file types (XML, Groovy, etc)
> 
> I also have some Eclipse settings for these which should be reasonably
> close, but I haven't extracted them yet.
> 
> I have also configured Checkstyle with a few whitespace checks.  This is
> now active for most of the Jenkins builds, including pull request
> builds.  Unfortunately, I had to disable the indent check, because it
> couldn't handle lines which have been broken and then indented an extra
> level.
> 
> So please make sure you use the correct indenting for each file, or we
> might have to reject your pull request:
> https://github.com/zanata/zanata-server/wiki/Coding-Guide
> 
> 
> Important note
> --------------
> 
> 
> If you have any outstanding branches/pull requests for zanata-server:
> 
> To minimise conflicts when merging, don't reformat your changes right
> away.  Please use this procedure in your feature branch:
> 
> 
> $ git fetch
> 
> # VERY, VERY IMPORTANT: merge everything *before* the reformat
> $ git merge 4bcf574b8a^
> 
> # Now, merge the reformat itself, but ignore reformatting where it conflicts
> $ git merge 4bcf574b8a -s recursive -X ours

The above step is more dangerous than I thought - when reformatting is
involved git sometimes fails to detect semantic conflicts.  (In one case
this led to two identical fields, and one missing field.)  If you have
really good test coverage, this might be okay, but otherwise read on...

If you have a small to medium change, it's probably best to do a normal
merge here, and just deal with the conflicts.  The merge option
-Xignore-all-space should cut down on the conflicts here.

If you have a larger change, you could try the recursive/ours merge, but
then replace your modified files using the first merge node above
("Merge from '4bcf574b8a^'").  It's a bit error-prone, so I would
recommend the other option if possible.

Either way, I hope the code you changed has good test coverage!

> 
> # NB: At this point, use your IDE to reformat your *modified* files
> only!  Please inspect the result visually.
> 
> # optional:
> $ git merge origin/master
> 
> # finally:
> $ git push your feature branch
> 
> Then we will review the merge to make sure it looks okay.
> 
> Let me know if that procedure doesn't work for you, and we'll sort
> something out.
> 
> Sean.
> 
> 
> PS if you want to review your changes across branches more easily, try this:
> 
> git config --global alias.wdiff "diff --color-words --ignore-all-space"
> 
> This creates a new "git wdiff" command which ignores whitespace.
> 
> 


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-devel/attachments/20131001/a7ee8a4b/attachment.sig>