13 ms·

I runned a code formatter in our code base. Years later I was still 'blamed' for many things in our code as few files were untouched.

jarofgreen 5y ago
At one company I did a project that among other things involved bringing in a code formatter. I deliberately tagged that commit with a generic author :-)
- ornornor 5y ago
  Haha, I did that too because most of our code is just so shitty I didn’t want the shame of it looking like I was the author.
Ashanmaril 5y ago
We recently converted our monolith codebase at work from windows-1252 encoding to UTF-8 and now the entire project looks like it was written by 1 guy
- deadbunny 5y ago
  I can't remember the command off the top of my head (on mobile) but you can exclude specific commits from things like blame for situations like this.
- account42 5y ago
  You had non-ASCII characters in every line?
david_allison 5y ago
You can fix this! Look into the "ignore revs" file option on git blame or the option: blame.ignoreRevsFile https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
thanksforfish 5y 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.
- imoverclocked 5y ago
  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...
  - Hokusai 5y ago
    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.
- ornornor 5y ago
  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.
praptak 5y ago
That's common. Most tools like Magit make it easy to dig down through multiple layers of formats, renames, refactors and typo fixes to find the commit that actually introduced something. It's usually called "blame previous revision".

jarofgreen 5y ago

At one company I did a project that among other things involved bringing in a code formatter. I deliberately tagged that commit with a generic author :-)

ornornor 5y ago
Haha, I did that too because most of our code is just so shitty I didn’t want the shame of it looking like I was the author.

Ashanmaril 5y ago

We recently converted our monolith codebase at work from windows-1252 encoding to UTF-8 and now the entire project looks like it was written by 1 guy

deadbunny 5y ago
I can't remember the command off the top of my head (on mobile) but you can exclude specific commits from things like blame for situations like this.
account42 5y ago
You had non-ASCII characters in every line?

david_allison 5y ago

You can fix this! Look into the "ignore revs" file option on git blame or the option: blame.ignoreRevsFile https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

thanksforfish 5y 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.

imoverclocked 5y ago
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...
- Hokusai 5y ago
  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.
ornornor 5y ago
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.

praptak 5y ago

That's common. Most tools like Magit make it easy to dig down through multiple layers of formats, renames, refactors and typo fixes to find the commit that actually introduced something. It's usually called "blame previous revision".