Add .gitattributes

[mgaffigan]

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]

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]

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]

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]

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.

[jonbartels]

@OpenIntegrationEngine/steering-committee discussed this issue and PR #111 on the steering committee call today.

Some key points:

• Can we do this with a linter instead of a .gitattributes? This would allow individual commits to have their line endings updated. This also includes things like indents, egyptian brackets, yoda conditions, etc. Spotless was suggested in Discord chat
• There is a desire to clean up line endings, BUT it is a lower priority
• Being able to merge from other forks is vital
• We do want consistency to avoid merge conflicts or odd diffs from say a Windows user changing one line in a PR and blowing line endings for a whole file

[mgaffigan]

@jonbartels, adding the gitignore does not affect any committed file or merged file, only new files added. Can you clarify what merge concern this refers to?

The only files being "modified" by the proposed solution are six mixed-eol files, and those do not need to be fixed if the group does not want them fixed.