Also, Windows users need to configure another
setting to avoid adding non-executable files to the repo with the executable
permission bits set. Using Windows file systems that don't properly support
Unix file permissions can cause issues with git "detecting" changes
in a file's permissions (or mode). The execute bit is impropertly set.
Set the config property core.fileMode to false after cloning the repository
to avoid this.
git config core.fileMode false
Once this option is set, if you do need
to commit a change to the executable bit on a file in the repository, you
will need to use the command:
git update-index --chmod=(+|-)x path
with the appropriate + or - to set or
clear the executable bit. For a new file, you will need to git add the
file before using the above command.
mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>,
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
> 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
*.c crlf=input ident
*.cpp crlf=input ident
*.h crlf=input ident
*.html crlf=input ident
*.java crlf=input ident
*.xsd crlf=input ident
# No EOL translation
# Binary. No EOL translation, no diff
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipse-dev