> On Dec 27, 2015, at 11:16 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>
>> Good luck finding the “bug fix” in a whole file reformat
>
> Do you mean "git blame" kind of thing?
>
I don’t think I worded my response very well…
I think one big commit changing all files would be much better than many small commits done “as you go”.
The problem, as I see it, with many small commits is that you would be intermixing reformatting changes with actual
codechanges; this would make it nearly impossible to find the “actual" changes within reformatted code.
> If the final state is the same, then there is no difference if it
> comes in a single commit or from a series of commits.
> "git blame" would be broken anyway, thus we'd better break it sooner.
>
Agreed. The only negative I can really see is that you almost "break history" at a single point in the code. By
“breakhistory” I mean a point at which you cannot simply diff back to and see just the relevant changes. This can be
overcomesimply by diff-ing older code up to just before the point of the reformat.
As you basically mentioned, this effect will happen at some point in either method, might as well make it all at one
pointin time.
> I think the way to go there is to enable the rules, execute checkstyle
> and enjoy all the 100500 errors. Then we configure
> <maxAllowedViolations>100500</maxAllowedViolations>. That would make
> sure new code is using proper names while the old one is either
> deleted eventually or updated.
>
If checkstyle supports that, sounds like a plausible solution, to ensure forward progress. Just ratchet the number
downas things are fixed.
>> with whole file reformats, e.g. “Fixed bug in generated SQL & formatted file to follow conventions”.
>
> I think it is undesired as it would definitely create lots of merge conflicts.
>
>> I should stop with my opinions here… that being said…
>
> Lack of feedback would be much worse.
Just kidding as this is danger
>
> Vladimir