bug: CRLF line ending weirdness on checkout

[DavisVaughan]

Did you check existing issues?

• [X] I have read all the tree-sitter docs if it relates to using the parser
• [X] I have searched the existing issues of tree-sitter-python

Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)

No response

Describe the bug

I have a question regarding the .gitattributes file in use here and in other tree-sitter grammar repos

If I do a clean clone of tree-sitter/tree-sitter-python, then I immediately get 3 diffs regarding line endings. Does this also happen to you all? This is just with a command line git clone call, followed by a git status. No IDE weirdness possible here. (This also happens in tree-sitter-c, for example)

They are related to the 3 crlf examples files, one of which is https://github.com/tree-sitter/tree-sitter-python/blob/master/examples/crlf-line-endings.py

Using git diff --color --word-diff-regex=. shows me a diff like this

i.e. the carriage return is getting stripped out if I were to recommit this file

I think it has something to do with this set of gitattributes https://github.com/tree-sitter/tree-sitter-python/blob/master/.gitattributes

If I set text=auto it magically goes away, but I doubt thats right (idk really).

---

I've tried all combinations of the core.autocrlf setting in my global gitconfig too, it is currently set to false to try and completely remove it from the equation.

Steps To Reproduce/Bad Parse Tree

NA

Expected Behavior/Parse Tree

NA

Repro

NA

[ObserverOfTime]

The issue is actually in the .editorconfig (shouldn't affect git but will affect every editor). Either end_of_line = lf should be removed or it should be overriden for crlf files.

[DavisVaughan]

I tried to make it clear above that this was purely with command line git and outside of any IDE - so I'm not totally sure how .editorconfig would come in here, do you see how?

[ObserverOfTime]

You're right, it also needs to be text=auto in .gitattributes.