wrong handling of text git attribute leading to files incorrectly reported as modified

I’m not a git expert and this might be the wrong place to ask this question, so please send me somewhere else if I’m in the wrong place.

I asked the same question on stack overflow, but didn’t get any response: http://stackoverflow.com/questions/22823004/files-incorrectly-reported-modified-git-attributes-buggy-leading-to-inconsist

If a file is committed with crlf line endings with the text attribute unset in the working tree, but the text attribute is set in the repo, the file will be incorrectly shown as modified - for all users checking out the file. Resetting or manually modifying the file will not help - The only remedy is to commit the .gitattributes with the text attribute set for the file.

Wouldn’t it be better to only consider the checked-in gitattributes instead of the attributes in the working tree? Is this a bug in git handling gitattributes or is this wrong usage? If it is wrong usage, is it documented anywhere?

The following shell script demonstrates the problem:

#!/bin/bash # creating a git repo "repo" rm -rf repo mkdir repo cd repo git init # committing gitattributes with text attribute set for all files echo "* text" > .gitattributes git add .gitattributes git commit -m "added .gitattributes" # add a file with CRLF line ending with text attribute unset echo -e "crlf\r" > crlffile echo "* -text" > .gitattributes git add crlffile git commit -m "added crlffile" git checkout .gitattributes # now "crlffile" shows as modified, even though it isn't. # only way to resolve is to modify .gitattributes git status crlffile # crlffile shown as modified. git checkout crlffile git status crlffile # crlffile shown as modified. git reset --hard git status # crlffile shown as modified. # git diff will report the CR as the difference git diff # but external diff reports no differences. git difftool --extcmd=diff --no-prompt

Thanks for your help Frank Ammeter

On 2014-04-11 22.20, Frank Ammeter wrote:

No. If you change stuff in your working tree (and .gitattributes is a part of the working tree) how should Git know what you want? The primary assumption is that you know what you are doing in the working tree.

I thinkk No, yes.

If it is wrong usage, is it documented anywhere? Please have a look here: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

And if you think that the documentation can be improved, please feel free to send suggestions.

A simple "git diff" is a good start, and a patch with a commit message is even better.

Am 11.04.2014 um 22:38 schrieb Torsten Bögershausen <tboegi@web.de>:

I don’t see that argument. I don’t know why at the time of a commit git should read unstaged files from my working tree - that affect my commit.

I’ve read this, can’t see anything about my problem in this document. No offense, but because I don’t understand the reasoning behind this, I can’t really help improve the documentation. I don’t think it makes much sense if I as a non-git-developer add something like „please apologize the git developers didn’t really think far enough when they invented git attributes, because they don't care if your repo gets inconsistent…"

Frank:

On Sat, Apr 12, 2014 at 7:29 AM, Frank Ammeter <git@ammeter.ch> wrote:

.gitignore works the exact same way. If you modify .gitignore then git status will immediately reflect those changes. You don't even have to store either file in the repository (.gitignore or .gitattributes). That is for your benefit, and for easily sharing that configuration with collaborators. Git only cares that the file exists in your working tree at run-time.

Regards,

Brandon McCaig <bamccaig@gmail.com> writes:

It is a lot more than "for sharing". If you made .gitignore only effective after it gets committed, you cannot test your updated version of .gitignore is correct before committing the change.

Am 15.04.2014 um 23:23 schrieb Junio C Hamano <gitster@pobox.com>:

Ok, I can follow that logic for .gitignore, but I was talking about .gitattributes and I always thought that .gitattributes as belonging to the repository, since it affects a) how files are checked out and b) how they are stored inside the repository. If committing .gitattributes were only for sharing convenience, git couldn’t decide whether to convert line endings when checking out a file. The same behavior doesn’t apply to .gitignore, because git will checkout a file that was added even though it matches an ignore pattern in .gitignore.

Frank Ammeter <git@ammeter.ch> writes:

They are conceptually the same thing, so if you can follow the logic for .gitignore, you already can follow the logic for .gitattributes.

The only two readons we have a separate .gitignore are because other SCMs had a similar mechanism, and because it came before attributes. If we didn't have these two constraints, it would have made a lot more sense to express "this path is to be ignored" by setting "ignored" attribute.

Am 11.04.2014 22:20, schrieb Frank Ammeter:

It is. In the repository is stored a crlffile with \r in it which would be changed when you would do a commit (with your current gitattributes)

No. This works too:

git add crlffile git commit -m . # practically removes the \r inside the repository git status crlffile #shows up clean