Hi, On Tue, Mar 4, 2014 at 10:47 AM, Davide Giannella <[email protected]> wrote: > I'm saying that with the proper tool in place this would have not happened > as the build would (potentially) break if the formatting is not good.
The trouble with such tooling is avoiding false positives. Where do you draw the line on valid formatting? For example many of the formatting changes in the troublesome patch seem equally valid before and after the change. Which one should such a tool prefer, and why? Basic stuff like using spaces instead of tabs would probably be OK to enforce in the default build, but already things like the correct indentation level becomes troublesome to enforce automatically. There are cases where it makes sense to break or bend the formatting rules for better readability, and I'd hate to loose that flexibility because of too strict formatting checks. > In any case I could have a precise report of file name and line number > of what is wrong and at the end even the committer should not care about > the formatting as a tool is taking care of it by highlighting in case of > problems. When submitting a patch, it's always a good practice to actually take a look at the diff and make sure that all the intended changes are included and nothing else. Just a few seconds of looking at https://github.com/apache/jackrabbit-oak/pull/9/files shows the problem. BR, Jukka Zitting
