.gitattributes

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