Torsten Bögershausen <tboegi@xxxxxx> writes: >> When the user has CRLF data in the index and the user tell the >> attribute system so that the next "add" would result in "fixing" the >> indexed lines to be terminated with LF, "diff-files" _should_ show >> that correction as a change, I think. > Fair enough. > There are 2 users here: > User 1 commits files with CRLF into the index, and later decides > to set the "text eol=crlf" attribute on it, without normalizing the repo. > > User 2 does a simple "git clone", which includes checkout. > Running "git diff" tells user 2, that his work tree is dirty. > > My conclusion is, that we could suppress the normalization for text files, > (as we do it for core.autocrlf with the new safer CRLF handling) > meaning that "git diff" and "git status" is clean and that files stay with CRLF > in the index. > Does this make sense ? Your example is for these two users to have conflicting settings on the line ending, but if user 1 commits files in latin-1 to a project where in-project data is expected to be UTF-8 and working tree files can be in latin-1, with necessary conversion done via clean/smudge filter, the user 2 would see a very similar symptom, wouldn't s/he? So I am not sure how your example supports a hack that treats CRLF conversion as something special among other conversions, without doing anything about clean/smudge filter. Besides, it is OK if your status and diff says your worktree is dirty immediately after cloning in such a broken situation, I would think. In fact, it may even be preferable to do so, in order to indicate that there is something unusual going on. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html