Re: [PATCH 1/3] git reset --hard gives clean working tree

Torsten Bögershausen [off-list ref] writes:

quoted

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.