Horrible TL;DR that isn't a TL;DR
Basically different editors and OS types do line endings differently, it's not as bad as it was in the past but it still happens (otherwise I wouldn't have made this PR out of past agony). Why is this bad you may ask? Well if your OS or editor uses a different type of line ending than someone else, it can be treated like invisible invalid characters when committed. This is where `.gitattributes` comes in, on commit it reads this file and enforces what standard type we want, so everyone can work however they want without issue :D
Here's an example image I stole from the second article:
.git-blame-ignore-revs
Luckily since only two files were impacted this one won't seem to do much at the moment, but for future references, this allows the late introduction of .gitattributes to be less painful.
If you really don't know what this does, basically it's a template file for when you use git-blame, it auto-adds the commit SHAs into the blame search so we never need to do it manually.
Here's an example with and without .git-blame-ignore-revs
Say in the future after the format enforcement that I wanted to check before that time, here are two instances of the same file with one change, the new-line between the last two brackets with my wonderfully helpful spasm commit name.
Why this might be annoying you may ask?
**OH WELL THAT'S BECAUSE IT CAN CAUSE DEAD ENDS IN THE GIT-BLAME TREE :)**
p.s.
I took more time writing these explanations than the actual PR
Xlinka
commented
1 year ago
About The Pull Request If You Don't Know What These Do
AKA preventing a future headache.
.gitattributes
If you really don't know how useful this file is and don't want to read my TL;DR or these articles from people who ACTUALLY know what they're talking about: https://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ https://dev.to/deadlybyte/please-add-gitattributes-to-your-git-repository-1jld
Horrible TL;DR that isn't a TL;DR
Basically different editors and OS types do line endings differently, it's not as bad as it was in the past but it still happens (otherwise I wouldn't have made this PR out of past agony). Why is this bad you may ask? Well if your OS or editor uses a different type of line ending than someone else, it can be treated like invisible invalid characters when committed. This is where `.gitattributes` comes in, on commit it reads this file and enforces what standard type we want, so everyone can work however they want without issue :D Here's an example image I stole from the second article: .git-blame-ignore-revs
Luckily since only two files were impacted this one won't seem to do much at the moment, but for future references, this allows the late introduction of
.gitattributesto be less painful.If you really don't know what this does, basically it's a template file for when you use
git-blame, it auto-adds the commit SHAs into the blame search so we never need to do it manually.Here's an example with and without .git-blame-ignore-revs
Say in the future after the format enforcement that I wanted to check before that time, here are two instances of the same file with one change, the new-line between the last two brackets with my wonderfully helpful spasm commit name.   Why this might be annoying you may ask? **OH WELL THAT'S BECAUSE IT CAN CAUSE DEAD ENDS IN THE GIT-BLAME TREE :)**p.s.
I took more time writing these explanations than the actual PR