Merge conflicts in .gitattributes can cause trouble

[Lars Schneider <larsxschneider@gmail.com>]

Hi,


If there is a conflict in the .gitattributes during a merge then it looks 
like as if the attributes are not applied (which kind of makes sense as Git 
would not know what to do). As a result Git can treat e.g. binary files 
as text and they can end up with changed line endings in the working tree. 
After resolving the conflict in .gitattributes all files would be marked 
as binary, again, and the user can easily commit the wrongly changed line 
endings.

Consider this script on Windows:

$ git init .
$ touch first.commit
$ git add .
$ git commit -m "first commit"

$ git checkout -b branch
$ printf "*.bin binary\n" >> .gitattributes
$ git add .
$ git commit -m "tracking *.bin files"

$ git checkout master
$ printf "binary\ndata\n" > file.dat # <-- Unix line ending!
$ printf "*.dat binary\n" >> .gitattributes # <-- Tell Git to keep Unix line ending!
$ git add .
$ git commit -m "tracking *.dat files"
$ git cat-file -p :file.dat | od -c
0000000   b   i   n   a   r   y  \n   d   a   t   a  \n 
                                ^^^^                ^^^^  <-- Correct!
$ git checkout branch
$ git merge master # <-- Causes merge conflict!
$ printf "*.bin binary\n*.dat binary\n" > .gitattributes # <-- Fix merge conflict!
$ git add .
$ git commit -m "merged"
$ git cat-file -p :file.dat | od -c
0000000   b   i   n   a   r   y  \r  \n   d   a   t   a  \r  \n
                                ^^^^^^^^                ^^^^^^^^  <-- Wrong!

Possible solutions:

1. We could print an appropriate warning if we detect a merge conflict 
   in .gitattributes

2. We could disable all line ending conversions in case of a merge conflict
   (I am not exactly sure about all the implications, though)

3. We could salvage what we could of the .gitattributes file, 
   perhaps by using the version from HEAD (or more likely, the ours stage of
   the index) -- suggested by Peff on the related GitHub issue mentioned below

Thoughts?

Thanks,
Lars


PS: I noticed that behavior while working with Git LFS and started a discussion
about it here: https://github.com/github/git-lfs/issues/1544