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

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

[Frank Ammeter]

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

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

[Torsten Bögershausen]

On 2014-04-11 22.20, Frank Ammeter wrote:
> 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?
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.
> Is this a bug in git handling gitattributes or is this wrong usage? 
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.

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

[Frank Ammeter]

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

> On 2014-04-11 22.20, Frank Ammeter wrote:
>> 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?
> 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?
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.

> The primary assumption is that you know what you are doing in the working tree.
>> Is this a bug in git handling gitattributes or is this wrong usage? 
> 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
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…" 

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

[Brandon McCaig]

Frank:

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

.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> <bamccaig@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bamccaig.com/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'

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

[Junio C Hamano]

Brandon McCaig <bamccaig@gmail.com> writes:

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

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.

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

[Frank Ammeter]

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

> Brandon McCaig <bamccaig@gmail.com> writes:
> 
>> 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.
> 
> 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.

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.

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

[Junio C Hamano]

Frank Ammeter <git@ammeter.ch> writes:

> Am 15.04.2014 um 23:23 schrieb Junio C Hamano <gitster@pobox.com>:
>
>> Brandon McCaig <bamccaig@gmail.com> writes:
>> 
>>> 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.
>> 
>> 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.
>
> Ok, I can follow that logic for .gitignore, but I was talking about .gitattributes...

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.

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

[Holger Hellmuth]

Am 11.04.2014 22:20, schrieb Frank Ammeter:
> #!/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.

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)

> # only way to resolve is to modify .gitattributes

No. This works too:

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