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

["Torsten Bögershausen" <tboegi@web.de>]

> I do not think I can endorse this approach, as I cannot explain why
> it could possibly make sense to treat as if CRLF conversion is
> somehow special among all the convert_to_git()/convert_to_worktree()
> conversions, which your patch does to the diff code.
>
> Comparisons between contents from two tree objects and comparisons
> between contents from a tree object and the index must happen
> without conversion, and comparisons between contents from the tree
> in the HEAD commit and contents from the working tree must be done
> in line with the HEAD vs index comparison to serve as a preview of
> what would happen after adding the contents taken from the working
> tree to the index, which means we should compare what is in the
> index (without conversion) and the result of running the whole
> convert_to_git() conversion on what is in the working tree.  It
> feels fundamentally wrong to apply only CRLF conversion without any
> other conversion, whether the direction of the conversion is from
> worktree to git or the other way around, when comparing two things.
>
> 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 ?