Re: [PATCH/RFC v2 1/4] Add "core.eolStyle" variable to control end-of-line conversion

From: Dmitry Potapov <dpotapov@gmail.com>
Date: May 10, 2010, 08:13 UTC
Message-ID: <20100510081358.GD14069@dpotapov.dyndns.org>
In-Reply-To: <20100509200935.GA22563@pvv.org>

On Sun, May 09, 2010 at 10:09:37PM +0200, Finn Arne Gangstad wrote:

Show 6 quoted lines

> 
> So maybe, just maybe, we can make everything sufficiently good by
> repairing "core.autocrlf = {input,true}" so that git will not convert
> a CRLF already in the repo. This would make autocrlf = true a safe
> default value (and probably input too, but you'd have to "do
> something" to get a new text file with CRLF into the repo then).

First of autocrlf is safe as it is implemented now. Second, to do something to get a new with CRLF into the repo is really stupid. The whole point of autocrlf is being automatic and do not have the user to worry about CRLF when he adds a new file.

The only real problem I am aware of is that some repository are not compatible with autocrlf conversion, because they store text files with different endings and do not have appropriate .gitatributes to describle what text files should and should not be converted. So, each user has to disable autocrlf in them manually and then re-checkout all files using (rm -rf * && git checkout -f), which is confusing for many users. In fact, you do not have to disable autocrlf, you can add a few lines to .git/info/attributes to make it autocrlf compatible, but again many users even not aware about this file, let alone what needs to be added. Further, the problem amplified by the fact that you have to do the same procedure every time when you do cloning, and though cloning is not most common operation, it happens often enough to annoy many users.

I believe that the right solution is to be able to enable autocrlf but only for those repositories that are marked as autocrlf compatible by upstream.

Dmitry