Is it possible to commit a file that defies the line ending behavior specified by .gitattributes?
.gitattributes file is added to given directory, with exactly the following content:
Is there any possible way that a new file or a previously normalized file (e.g. all LF line-endings) could be committed to that directory and not be normalized? I.e., is there any possible way that new CRLF line endings could be introduced into the repository after enabling
text mode specified?
- Kernel bash scripts compilation error
- Force SourceTree ignore line endings in git files
- Cherry-pick with ignore whitespace / line-endings
- git crlf configuration in mixed environment
- Normalizing line endings in a git repository with many branches
- Git command to checkout another branch when .gitattributes makes git think local changes were made
To paraphrase again, is this
.gitattributes file an absolutely foolproof way to prevent new CRLF lines from being committed to
*.txt files in the directory that contains the
.gitattributes file? I want to convince my colleagues that the
.gitattributes file is entirely sufficient, and that further measures to exclude CRLFs (e.g. a server-side hook) are unnecessary.
An answer should either confirm that it is impossible to override the line-ending behavior specified by
.gitattributes, or provide a counterexample explaining how one could circumvent the
.gitattributes file and sneak in some CRLF line endings.
2 Solutions collect form web for “Is it possible to commit a file that defies the line ending behavior specified by .gitattributes?”
Not easily through
gitattributes, since negative pattern are forbidden.
There is actually a patch being proposed this days (March 2013) to Make
So you need to put a global rule like
*.txt only in
.gitattributes files present in sub-directories where you known you won’t need CRLF.
And reserve more fine-grained
text rules in
.gitattributes present in directories with mixed content.
kostmo mentions in the comments the EGit bug 421364:
Until this is implemented, I recommend this setup:
- For each Eclipse project, go to
Properties > Resourceand change “
New text file line delimiter” to
Other: Unix. Commit the resulting
- Don’t configure any
core.autocrlf” for Git.
This means that files will have the same line endings in the working directory as in the repository. Git and EGit will not convert any file contents.
With 1., all new files that are created in Eclipse will have correct (
LF) line endings, even when created by a user on Windows.
For files that are already in your repository with
CRLF, you can fix them and commit the result. I recommend using
fromdoson the command line.
Note: that issue (bug 421364) has just now (March 25th, 2014) been requalified as duplicate of bug 342372 by Lars Vogel.
So, the support of
.gitattributes by JGit is “assigned”, but its implementation is
still in progress.
The implementation is being reviewed (January 2015):
- “review 1614” Add basic support for
Core classes to parse and process
.gitattributesfiles including support for reading attributes in WorkingTreeIterator and the dirCacheIterator.
- “review 35377” Adds the git attributes computation on the treewalk
getAttributesfeature to the tree walk.
The computation of attributes needs to be done by the
TreeWalksince it needs both a
To paraphrase again, is this .gitattributes file an absolutely foolproof way
No. Git has a lot of conveniences to make the usual tasks easy and put speedbumps in the way of questionable things, but it won’t limit your control over your own repo.
I want to convince my colleagues that the .gitattributes file is entirely sufficient, and that further measures to exclude CRLFs (e.g. a server-side hook) are unnecessary.
They are necessary. Nobody can control what others do in their own repos.
git update-index --cacheinfo \ 100644,`git hash-object -w --no-filters path/to/file`,path/to/file
From the git hash-object docs
Hash the contents as is, ignoring any input filter that would have been chosen by the attributes mechanism, including the end-of-line conversion. If the file is read from standard input then this is always implied, unless the –path option is given.