Am 11.04.2014 um 22:38 schrieb Torsten Bögershausen <tbo...@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:
>> 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?
> 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
>> 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:
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
„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
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