Over the past decade, there have been a couple of attempts to remedy the situation regarding line endings (Windows/DOS line endings are traditionally CR/LF even if many current applications can handle LF, too, Linux/MacOSX/*BSD/Unix uses LF-only line handlings, and old MacOS software used to use CR-only line endings). The current idea seems to be that the default line endings differ depending on the platform, and for files that should be exempt from that default, we strongly recommend using .gitattributes to define what the source code requires. It is time to heed our own recommendation and mark the files that require LF-only line endings in our very own .gitattributes. For starters, those files include shell scripts: the most prevalent shell interpreter in use (and certainly used in Git for Windows) is Bash, and Bash does not handle CR/LF line endings gracefully. There are even two shell scripts that are used in the test suite even if they are not technically supposed to be part of core Git, as indicated by their habitat inside contrib/: git-new-workdir and git-completion.bash. Related to shell scripts: when generating common-cmds.h, we use tools that generally operate on the assumption that input and output deliminate their lines using LF-only line endings. Consequently, they would happily copy the CR byte verbatim into the strings in common-cmds.h, which in turn makes the C preprocessor barf (that interprets them as MacOS-style line endings). Further, the most obvious required fixes concern tests' support files committed verbatim, to be compared to Git's output, which is always LF-only. There are a few SVN dump files, too, supporting the Subversion-related tests, requiring LF-only line endings. Finally, the test suite makes use of text files that are not obviously supporting tests, such as t/README, comparing them to LF-only versions (and consequently failing if the files have been checked out with CR/LF line endings). Therefore we need to mark those as LF-only in the .gitattributes, too. Without these fixes, Git will fail to build and pass the test suite, as can be verified even on Linux using this cadence: git config core.autocrlf true rm .git/index && git stash make DEVELOPER=1 -j15 test Note: I separated out the change marking t/t4051/* as LF-only into an individual commit for one reason: it would appear that the test passes if checked out using core.autocrlf=true on Linux, but on Windows the test fails. In that respect, this test is special, as the other changes can be easily validated even without using Windows. Johannes Schindelin (5): Fix build with core.autocrlf=true git-new-workdir: mark script as LF-only completion: mark bash script as LF-only Fix the remaining tests that failed with core.autocrlf=true t4051: mark supporting files as requiring LF-only line endings .gitattributes | 8 +++++++- contrib/completion/.gitattributes | 1 + contrib/workdir/.gitattributes | 1 + git-gui/.gitattributes | 1 + t/.gitattributes | 29 ++++++++++++++++++++++++++++- 5 files changed, 38 insertions(+), 2 deletions(-) create mode 100644 contrib/completion/.gitattributes create mode 100644 contrib/workdir/.gitattributes base-commit: d2bbb7c2bcf6e77ebfcabf4e12110fe6d5c91de6 Published-As: https://github.com/dscho/git/releases/tag/lf-attrs-v1 Fetch-It-Via: git fetch https://github.com/dscho/git lf-attrs-v1 -- 2.12.2.windows.2.800.gede8f145e06