I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
If it's a new code base or new file, agreed. But what about modifying a legacy file to introduce/change actual functionality -- the automated formatter/linter may obscure the actual changes with a complete reformat, correct?
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
To your point, do it in a separate commit. Run the formatter/linter one time manually across the entire codebase. This will provide a basis (momentum) and from then on only changed files need to be formatted/linted (which could be automated).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed about momentum and separate commit.
However, most of your points are moot when automating this process with a formatter/linter as suggested.
If it's a new code base or new file, agreed. But what about modifying a legacy file to introduce/change actual functionality -- the automated formatter/linter may obscure the actual changes with a complete reformat, correct?
To your point, do it in a separate commit. Run the formatter/linter one time manually across the entire codebase. This will provide a basis (momentum) and from then on only changed files need to be formatted/linted (which could be automated).