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

From: Tarmigan <tarmigan+git@gmail.com>
Date: Aug 3, 2008, 18:54 UTC
Message-ID: <905315640808031154j28778cd6pee75e6b008304941@mail.gmail.com>
In-Reply-To: <20080803173339.GQ7008@dpotapov.dyndns.org>

On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:

Show 6 quoted lines

> On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
>>
>> 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