Is it possible to commit a file that defies the line ending behavior specified by .gitattributes?

Question

If a .gitattributes file is added to given directory, with exactly the following content:

*.txt    text

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 .gitattributes with text mode specified?

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.

Answer 1

Not easily through gitattributes, since negative pattern are forbidden.

There is actually a patch being proposed this days (March 2013) to Make !pattern in .gitattributes non-fatal.

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:

1. For each Eclipse project, go to Properties > Resource and change "New text file line delimiter" to Other: Unix. Commit the resulting .settings/org.eclipse.core.runtime.prefs files.
2. Don't configure any .gitattributes or "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 dos2unix or fromdos on 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 .gitattributes

Core classes to parse and process .gitattributes files including support for reading attributes in WorkingTreeIterator and the dirCacheIterator.

• "review 35377" Adds the git attributes computation on the treewalk

Adds the getAttributes feature to the tree walk.
The computation of attributes needs to be done by the TreeWalk since it needs both a WorkingTreeIterator and a DirCacheIterator.

---

Update August 2018: the bug mentioned above (bug 342372) depends on JGit bug 537410, which just got resolved.
"JGit rebase and stash dont preserve line endings"

The problem is that the ResolveMerger during processEntry() does not remember the CheckoutMetadata (in which JGit stores filters and eol-attributes) for the files and then checks them out in checkout() ignoring any attributes or filters.

ResolveMerger.cleanUp() has the same problem.

JGit commit 4027c5c (from review 127290) should fix that.
THanks to Thomas Wolf an active contributor to JGit.

That gives hope for EGit:

EGit in general leaves all this eol handling in staging/merging/checkout to JGit.
The only places where EGit has to care about it is in the compare framework when it has to read index entries itself, and there it already properly handles CheckoutMetadata.

Answer 2

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

--no-filters
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.