[zanata-devel] The great Zanata reformat of 2013

[Sean Flanigan]

On 2013-10-01 12:41, Sean Flanigan wrote:
> 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.

Correction: use "-Xignore-space-change", not -Xignore-all-space

> 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/de5f0759/attachment.sig>