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

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.

  • Dealing with files that Git refuses to reset?
  • Git attribute core.autocrlf applies on clone, but not on checkout
  • git show modify files but i don't change anything git reset did not work
  • Git, push commits one more time with different line endings
  • Cherry-pick with ignore whitespace / line-endings
  • On git line-endings again
  • Why does Git convert CRLF to LF on Linux?
  • git diff - show me line ending changes?
  • 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 !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.

    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.

    Git Baby is a git and github fan, let's start git clone.