On Sun, May 09, 2010 at 10:09:37PM +0200, Finn Arne Gangstad wrote:
quoted text
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html