1 # ensure LF endings on all checkouts
2 configure.ac crlf=input
4 # ensure native line endings on checkout
15 # don't do anything to line-endings. Let CRLFs go into the repo, and CRLF on checkout
24 # The ideal situation would be to do no EOL normalization. Each file
25 # would have a default EOL, and tools on Windows and Linux would handle
28 # We're not in the ideal world. A popular editor on Windows (possibly
29 # Visual Studio) silently introduces EOL corruption -- it displays an
30 # LF-file normally, but any newly added lines have CRLF. On Linux,
31 # Emacs and versions of VI handle LF-files and CRLF-files properly.
32 # However, emacs doesn't like files with both LF and CRLF EOLs. Editing
33 # the file without additional action will increase the EOL corruption
36 # Another vector for mixed EOLs is scripts. We mostly don't have scripts
37 # that add new lines -- so we rarely see this. However, one major event
38 # in the tree was the addition of copyright headers using a script. That
39 # script introduced EOL corruption.
41 # Any automated EOL normalization of files already in the repository will
42 # cause difficulties in traversing histories, assigning blame, etc. So, we
43 # don't want to change what's in the repository significantly, even if it
48 # a) we ensure that there's no further corruption of LF-files. So, we use
49 # git's 'crlf' attribute on those files to ensure that things are fine
50 # when we work on Windows. We could use 'crlf=input', but it doesn't buy
51 # us much -- we might as well be working with consistent EOLs for files in
52 # working directories as well as in the repository
54 # b) if the file already of CRLFs, we don't do any normalization. We use '-crlf'
55 # so that git doesn't do any EOL-conversion of the file. As I said, this
56 # is mostly harmless on Linux. We can't mark these files as 'crlf' or use
57 # the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents
58 # _inside_ the repository [1], and hence makes history traversal annoying.
59 # So, we live with occasional EOL corruption.
61 # c) We can handle mixed-EOL files on a case-by-case basis, converting them to
62 # LF- or CRLF-files based on which causes fewer lines to change
64 # d) We try to ensure no further headaches, by declaring EOL normalization on
65 # code files, and Unix-flavoured files, like shell-scripts, makefiles, etc.
67 # [1] GIT use LFs as the normalized internal representation.