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

On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:

[...]

I deem it not, uhm, magical.  By your reasoning there should be a  
way for
Git to convert a file to UTF-8 when some entertaining person  
converted the
working directory file to ISO-8859-15.

Um, what?  This discussion is about figuring out when Git should mess  
with the line endings a user is trying to commit.  Why are you  
bringing character encodings into it?  Git does not (to my knowledge)  
have any "utf8" setting that converts all files to UTF-8, and  
certainly not one that is enabled by default on Windows.

Being able to mark a file with an "enforce crlf line endings on this  
file" flag is useful _given that Git messes with line endings_, and a  
"do not mess with line endings in this file" flag does not achieve the  
same purpose.  Okay?

If you want my personal opinion on autocrlf, I was happier when Git  
left line endings alone so I didn't have to worry about the files I  
commit being mangled (however reversibly).

I think "autocrlf=input" can make sense on a per-repository basis, but  
I would have it somewhere versioned like .gitattributes, so that (a)  
it is propagated when the repository is cloned, and (b) it is possible  
to take an existing repository with checked-in CRLFs and do a one-time  
conversion that also adds the "autocrlf=input" setting  
to .gitattributes (or wherever the setting ends up going).

I don't use "autocrlf=true", even on Windows, so I don't have any  
opinion on it other than thinking it should be a per-user setting  
rather than per-repository (but with a per-platform default :).  I  
don't see how it could work unless the repository has normalised line  
endings, though.

My background: I have a ton of repositories imported from CVS with a  
sordid mix of CR and CRLF (occasionally in the same file!).  Using  
these repositories with "autocrlf=true" is a pain in the arse since  
CRLFs in the repository cause spurious changes after a clean checkout,  
merge troubles, etc.  The code is supposed to build on Windows as well  
as Unix, so I got bit by this when msysgit changed the default  
autocrlf setting. [1]

My workaround is simply to set autocrlf=false; another solution might  
be to filter-branch all CRLFs out of the repository, but then I'd be  
messing with a lot of history, possibly breaking the files that  
actually need CRLFs, and for no real upside.  No thanks.

Okay, this turned into a longer rant than I intended; what I'm trying  
to say is that I think autocrlf(=true) as it is currently implemented  
is pretty useless, and that a setting that is versioned and cloneable  
would be better.  Phew!
-- 
Eyvind Bernhardsen


Footnote:
1. Your impression that people were rude when "autocrlf=true" was made  
the default on msysgit might be related to the fact that nobody had  
considered what would happen to existing repositories before making  
the change?  Steffen Prohaska wrote in response to one such complaint:

Unfortunately, existing repositories that contain the wrong line  
endings
suffer from the problems you described above.  This can be handled
either by switching off autocrlf, as you propose, or by cleaning up  
the
line endings.

(http://groups.google.com/group/msysgit/browse_thread/thread/978a3435c1cb0c81/70bac514a8b438ef?lnk=gst#70bac514a8b438ef 
)

Steffen went on to propose a patch to make autocrlf a sticky per- 
repository setting, but I think you shot it down.