You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm seeing carriage returns showing up in places where they don't belong in recent commits, which will certainly lead to spurious diffs in future pull requests. Perhaps a repository .gitattributes file can be used to correct this issue in the future. Also, it may be worth adding a small section to the readme informing Windows contributors of the CRLF vs LF issue, as they may want to config their git to checkout as-is and commit unix-style in the future. At least they should just be aware of the issue.
The text was updated successfully, but these errors were encountered:
Hi, this sounds like a good idea. So do I understand well that if we add a .gitattribute file git will transparently handle the conversion during commit?
For windows people, I think the line ending setting is a question during installation, so it might not be necessary to repeat it in our readme.
I'm seeing carriage returns showing up in places where they don't belong in recent commits, which will certainly lead to spurious diffs in future pull requests. Perhaps a repository .gitattributes file can be used to correct this issue in the future. Also, it may be worth adding a small section to the readme informing Windows contributors of the CRLF vs LF issue, as they may want to config their git to checkout as-is and commit unix-style in the future. At least they should just be aware of the issue.
The text was updated successfully, but these errors were encountered: