Re: Merge conflicts in .gitattributes can cause trouble

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Lars,

On Tue, 4 Oct 2016, Lars Schneider wrote:

> If there is a conflict in the .gitattributes during a merge then it looks 
> like as if the attributes are not applied

I tried to replicate this behavior, to the point where I wrote a patch
that demonstrates the breakage so I could single-step in a debugger to
find out where things go wrong, and fix them.

Alas, I found out that the .gitattributes are read *before* any merge
conflict arises in the case you demonstrated. Which kind of makes sense,
because the gitattributes decide over which merge driver to use, among
other things.

So in your example:

> 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

At this point, the .gitattributes list only .bin files as binary. That is
the revision of the .gitattributes used by this command:

> $ git merge master # <-- Causes merge conflict!

And as a consequence, the .gitattributes do not tell Git that it should
handle .dat files as binary. Which means that...

> $ 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!

... this is actually expected! Why? Because the .gitattributes that were
in effect when the user asked to perform a merge said so.

If you adjust .gitattributes *before* merging `master`, it works as you
would expect: the line endings are not changed.

The reason to do it this way: we want to respect the .gitattributes as per
the current worktree. We go even so far that we respect uncommitted
changes to said file...

> 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

I would vote for:

4. We keep letting Git read in the *current* version of .gitattributes
   *before* the merge, and apply those attributes while performing the
   merge.

Ciao,
Dscho