This will have a lot of files where it looks like every line has changed, because it has - the line endings.
We previously added a .gitattributes with this line:
* text=auto
That tells git that when committing any files, always use lf for line endings. The problem is that this project has a number of files that already had crlf (windows) line endings. The change to the .gitattributes only affects when changes are made and committed going forward, it did not affect the existing files.
That would mean, any time one of those files with the crlf line endings was changed - when you commit that file, it converts them to lf which makes it show every line has changed. That makes it difficult to follow the "real" changes, you have to tell it to ignore whitespace.
So in this commit, I run:
git add --renormalize .
That tells it to re-normalize all line endings. The down side is that the git history will be hard to see on these files. The 2 upsides are, first that we were already "starting fresh" just a few months ago, so it is still early in the history anyways. And second, that it is done in a single PR instead of slowly over time as each file is changed, so it kind of rips the bandaid off and we get all the pain at once.
This will have a lot of files where it looks like every line has changed, because it has - the line endings.
We previously added a
.gitattributeswith this line:That tells git that when committing any files, always use
lffor line endings. The problem is that this project has a number of files that already hadcrlf(windows) line endings. The change to the.gitattributesonly affects when changes are made and committed going forward, it did not affect the existing files.That would mean, any time one of those files with the
crlfline endings was changed - when you commit that file, it converts them tolfwhich makes it show every line has changed. That makes it difficult to follow the "real" changes, you have to tell it to ignore whitespace.So in this commit, I run:
That tells it to re-normalize all line endings. The down side is that the git history will be hard to see on these files. The 2 upsides are, first that we were already "starting fresh" just a few months ago, so it is still early in the history anyways. And second, that it is done in a single PR instead of slowly over time as each file is changed, so it kind of rips the bandaid off and we get all the pain at once.
Fixes #119