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

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@web.de> 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.