Skip to content

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

Open
mgaffigan opened this issue May 30, 2025 · 4 comments
Open

Add .gitattributes #110

mgaffigan opened this issue May 30, 2025 · 4 comments

Comments

@mgaffigan
Copy link
Contributor

mgaffigan commented May 30, 2025

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 run git add --normalize .

Here's the top file extensions and their formats as of today (output of git ls-files --eol):

Extension i/crlf i/lf i/mixed i/none i/-text Grand Total
.xml 6267 136 0 0 0 6403
.java 569 1223 4 0 1 1797
.jar 0 0 0 0 455 455
.png 0 0 0 0 113 113
.sql 44 53 0 11 0 108
.form 0 62 0 0 0 62
.js 3 38 0 2 0 43
.txt 19 14 1 5 0 39
.properties 11 7 0 0 0 18
.css 4 11 0 3 0 18
.hl7 0 14 0 0 1 15
.md 0 9 0 0 0 9
.classpath 3 4 1 0 0 8
.project 7 1 0 0 0 8
.vmoptions 0 5 0 0 0 5
.tld 0 5 0 0 0 5

Full table.

@tonygermano
Copy link
Member

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?

@mgaffigan
Copy link
Contributor Author

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.

@tonygermano
Copy link
Member

tonygermano commented May 31, 2025

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 i/mixed column in your table, and thankfully, it looks like there are very few of those.

@mgaffigan
Copy link
Contributor Author

Ya' know: some days I really hate git. Apparently text=auto will not complain if you have a mix of EOL's in the repository, while text will.

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.

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

No branches or pull requests

2 participants