Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set

On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov [off-list ref] wrote:

On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:

quoted

For all I care, git can consider the files as binary, but by *default*
I should get back the same as I put in.

Sorry, but Git is a source control system,

I think this is the heart of the disagreement.  What I love about git
is that git trusts me, the user, and it trusts my files.  It doesn't
change the encoding of my filenames by default.  It doesn't do keyword
expansion by default.  It doesn't change the case of filenames by
default.

If git is not willing to change the encoding/case of file*names* by
default, how is it acceptable to change the *content* of the files
themselves?

Yes, some systems that define themselves as "source control
management" systems make these changes for you.  But that sometimes
leads to frustrating and hard to understand (to the user) behavior.
Git has a very simple and transparent mental model, which is one of
it's greatest strengths.  In my humble opinion, autocrlf breaks this
simple "content tracker" model.

Breaking this mental model bothers me much more than the practical
issues involved with autocrlf, so I'm just going to drop that line of
argument.

Thanks,
Tarmigan