Hacker News new | ask | show | jobs
by thanksforfish 1786 days ago
I think it's best to migrate to a preferred formatting slowly, versus touching everything at once. I've had open pull requests that I've started over due to aggressive reformatting like that. Between that and breaking tools like 'git blame', it can be painful.
2 comments

Ran into this issue where contributors editors were reformatting the whole file they touched based on the newly created code formatting config file. Some editors would pick it up and automatically reformat on save so a commit with 3 actual lines changed looked like 90% of the file had changed in the diff. So we went with the nuclear option and did one massive PR that reformatted the whole codebase.
This approach sometimes works for formatting but the issue with ad-hoc approaches is finding ways of enforcing on new commits. This is especially so with a large developer base.

Once you move on from just banal issues like whitespace and move your way up to actual structural concepts in the code, ad-hoc starts completely falling apart (at least in my experience.)

I once encountered someone who did a giant re-formatting of code by rewriting past commits. Pretty disruptive for a day but did manage to keep history in-tact. Also, a little (or a lot?) dangerous...

That was our problem. We added a git hook to reject new malformed commits. The easier way to not mess more things was to make all the code base compliant.