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:

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:

# 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--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to