Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce end-of-line normalization #683

Closed
micove opened this issue Jul 29, 2015 · 5 comments
Closed

Introduce end-of-line normalization #683

micove opened this issue Jul 29, 2015 · 5 comments

Comments

@micove
Copy link
Contributor

micove commented Jul 29, 2015

Hello,

The repository seems to have some files with windows EOL and other with Linux EOL. Since different developers may have system wide settings that differ it would be nice if a .gitattributes file was added so there are no more EOL issues when people do PR. Some editors like MSVS change EOL silently and asking everyone to change their system configuration is harder than just use a per-repository setting which ensures it always work.

Here is a github take on this:
https://help.github.com/articles/dealing-with-line-endings/

Here is a .gitattributes file I used with success. It could be expanded or modified if needed.

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
*.props text eol=crlf
*.vcxproj text eol=crlf
*.vcxproj.filters text eol=crlf

The .gitattributes files only affect new commits so the existing file need a one time normalization. As taken from http://git-scm.com/docs/gitattributes this does the trick

$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

After doing this I got

500 files changed, 117536 insertions(+), 117528 deletions(-)

Now all files in .git are stored with LF. On checkout it will use the native EOL except for the VS files which will always checkout with CRLF.

To test this I went out of my way and changed all the line endings to LF to try and make a EOL error and git correctly warned me and did not introduce EOL changes and kept using CRLF since I was on windows. Basically git will always ignore EOL in commits now and github will not throw fits since to github all the files have LF.

At first glance 500 files changed may seem to introduce a lot of rebasing for PR and branches but looking at the list most of the files affected are MSVS and 3rdparty files. Which should not introduce that many merge conflicts.

This is more of a wishlist kind of thing but seems useful since I have seen EOL issues in several PR in the past.

@gregory38
Copy link
Contributor

I vote 👍 for this feature.

@micove
Copy link
Contributor Author

micove commented Jul 30, 2015

Here is a branch I made:
https://github.com/micove/pcsx2/tree/gitattributes

Doing

git log --stat

shows the 499 files changed since 500 (499 + .gitattribute) files are too much to be displayed in github.

@gregory38
Copy link
Contributor

Do you prefer that we do that now (with potential conflict with your PR #690) of after the merge of the previous PR.

@micove
Copy link
Contributor Author

micove commented Aug 4, 2015

@gregory38
I can redo my PR in 5 mins. It actually makes it smaller since 5000 changes are about EOL.

I have no idea when my windows PR will get merged if it's going to be merged at all so might as well do it now.

@gregory38
Copy link
Contributor

Ok. Done. Thanks for the info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants