1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
# diff settings
*.cs diff=csharp
# ensure LF endings on all checkouts
configure.ac crlf=input
config.rpath crlf=input
configure.host crlf=input
mkinstalldirs crlf=input
*.sh crlf=input
*.sources crlf=input
.gitattributes crlf=input
*akefile* crlf=input
m4/mono-output.m4 crlf=input
# ensure native line endings on checkout
*.c crlf
*.h crlf
*.cs crlf
*.il crlf
*.sln crlf
*.*proj* crlf
*.bat text eol=crlf
*.cmd text eol=crlf
# don't do anything to line-endings. Let CRLFs/LFs go into the repo, and CRLF/LFs on checkout
*.xml -crlf
# CRLF Handling
# -------------
#
# The ideal situation would be to do no EOL normalization. Each file
# would have a default EOL, and tools on Windows and Linux would handle
# both EOL formats.
#
# We're not in the ideal world. A popular editor on Windows (possibly
# Visual Studio) silently introduces EOL corruption -- it displays an
# LF-file normally, but any newly added lines have CRLF. On Linux,
# Emacs and versions of VI handle LF-files and CRLF-files properly.
# However, emacs doesn't like files with both LF and CRLF EOLs. Editing
# the file without additional action will increase the EOL corruption
# in the file.
#
# Another vector for mixed EOLs is scripts. We mostly don't have scripts
# that add new lines -- so we rarely see this. However, one major event
# in the tree was the addition of copyright headers using a script. That
# script introduced EOL corruption.
#
# Any automated EOL normalization of files already in the repository will
# cause difficulties in traversing histories, assigning blame, etc. So, we
# don't want to change what's in the repository significantly, even if it
# causes trouble.
#
# What we do now:
#
# a) we ensure that there's no further corruption of LF-files. So, we use
# git's 'crlf' attribute on those files to ensure that things are fine
# when we work on Windows. We could use 'crlf=input', but it doesn't buy
# us much -- we might as well be working with consistent EOLs for files in
# working directories as well as in the repository
#
# b) if the file already of CRLFs, we don't do any normalization. We use '-crlf'
# so that git doesn't do any EOL-conversion of the file. As I said, this
# is mostly harmless on Linux. We can't mark these files as 'crlf' or use
# the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents
# _inside_ the repository [1], and hence makes history traversal annoying.
# So, we live with occasional EOL corruption.
#
# c) We can handle mixed-EOL files on a case-by-case basis, converting them to
# LF- or CRLF-files based on which causes fewer lines to change
#
# d) We try to ensure no further headaches, by declaring EOL normalization on
# code files, and Unix-flavoured files, like shell-scripts, makefiles, etc.
#
# [1] GIT use LFs as the normalized internal representation.
|
