-
Notifications
You must be signed in to change notification settings - Fork 16
Add .gitattributes #110
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
Comments
This one I'm not sure about. It would be nice if they were normalized, but I really am not fond of a huge commit that completely rewrites hundreds of files and masks prior changes when viewing the blame. Most editors seem to detect line endings on file open and set it accordingly for new lines while editing the file (as long as people aren't using Notepad or something.) I think my preference would be that any edits use the line endings that already appear in the file being modified (same as indent settings when they are not consistent.) Not saying that I couldn't be swayed, though. I haven't looked, but is there a way to only enforce the line endings to LF on new files rather than file modifications? |
I agree that the huge commit is troublesome. I wouldn't want my name on so large a normalization commit. I think the design of .gitattributes is that it is supposed to be only for new files, but I don't think that works if autocrlf=true (which is the default for windows). Not sure. Not a git expert. It should be possible to reduce or avoid the large commit by keeping Java and XML as a mix of EOLs. I can play around with it some. |
Is there an easy way to tell if there are mixed line endings within the same file? I'd be open to normalizing those if they exist, and then possibly having some check (maybe in github actions?) to ensure that mixed line endings are not introduced in the same file. edit: I just noticed the |
Ya' know: some days I really hate git. Apparently In any case, PR updated to avoid the need to renormalize, and to fix the 6x mixed-EOL files. I'm no longer aware of any ill effect from merging. |
Uh oh!
There was an error while loading. Please reload this page.
If I'm missing something here, please say so, but it seems like there's not much consistency on whether the repo uses CRLF or whether it uses LF. Most projects specify a .gitattributes to ensure the repo is stored in LF, and each contributor ends up with an appropriate EOL according to their system preference.
I don't think anything is broken with the status quo per-se, and to fix this would be a huge commit, but it is likely worth doing at some point.
A minimal (still acceptable) .gitattributes would just be
* text=auto
, then rungit add --normalize .
Here's the top file extensions and their formats as of today (output of
git ls-files --eol
):Full table.
The text was updated successfully, but these errors were encountered: