Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Planning Meeting Notes - September 28, 2011

> - How to deal with line delimiters in Git?
> In CVS, the default was to have ASCII files converted on checkout
> and commit. The repo only contained LF.
> In Git, the core.autocrlf option is false by default, which means
> that new files from Windows machines are checked in unchanged with
> CRLFs. To keep the repo "clean" (with only LFs), we should either
> set project-specific line delimiters for new files to UNIX or set
> core.autocrlf=true. Does anybody have experience with autocrlf? Does
> it work in EGit?

First solution is to ban all Windows users :-) Given that this is unrealistic, here is what we do in OSGi.

We tell Windows users to set core.autocrlf=false. Setting it to true is problematic. The ideal is to have the files have LF line endings all the time. In the repo and in each user's workspace. Setting core.autocrlf=true will cause git to convert files to crlf on checkout so they are no longer the same as what is in the repo. You are also at the mercy of what git thinks is a text file and should be converted to crlf.

There is also core.eol=lf: "This setting forces git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out." This setting was added in git 1.7.2 but some users may be using older versions of git. You also must mark which files are "text" in the .gitattributes file. Since you need to mark file patterns as text in .gitattributes anyway, you can also set the eol setting in the same place. In OSGi, we use the older crlf=input setting which is equivalent to the newer eol=lf setting in .gitattributes (but works with pre-1.7.2 git). Either will mark the file pattern as text file as well as specify the EOL treatment. Setting this in the .gitattributes file which is committed to the repo means you are not at risk of the user forgetting to git config core.eol=lf in their local repo.

So, in summary, users must set core.autocrlf=false and each repo needs a .gitattributes file to control the desired line ending state for the text files in the repo. Here is the .gitattributes we use at OSGi.

# Text files with LF eol
*.auth crlf=input
*.awk crlf=input
*.bnd crlf=input
*.c crlf=input ident
*.conf crlf=input
*.cpp crlf=input ident
*.css crlf=input
*.ddf crlf=input
*.ee crlf=input
*.groovy crlf=input
*.h crlf=input ident
*.html crlf=input ident
*.java crlf=input ident
*.js crlf=input
*.lib crlf=input
*.MF crlf=input
*.perm crlf=input
*.php crlf=input
*.pl crlf=input
*.prefs crlf=input
*.properties crlf=input
*.py crlf=input
*.schema crlf=input
*.sh crlf=input
*.tcl crlf=input
*.txt crlf=input
*.xml crlf=input
*.xsd crlf=input ident
*.xsl crlf=input
*.xslt crlf=input
.classpath crlf=input
.project crlf=input
packageinfo crlf=input
Makefile crlf=input

# No EOL translation
*.bat -crlf

# Binary. No EOL translation, no diff
*.ico binary
*.jpeg binary
*.jpg binary
*.png binary
*.crt binary
*.pdf binary
*.dll binary
*.jar binary
*.jnilib binary
*.so binary
*.zip binary
*.doc binary
*.ppt binary
*.xls binary
*.odg binary
*.odp binary
*.ods binary
*.odt binary
*.otg binary
*.otp binary
*.ots binary
*.ott binary
*.key binary
*.numbers binary
*.pages binary

Back to the top