Re: CRLF problems with Git on Win32

[Abdelrazak Younes <younes.a-GANU6spQydw@public.gmane.org>]

Linus Torvalds wrote:
> 
> 
> On Tue, 8 Jan 2008, Dmitry Potapov wrote:
>> Perhaps, this option can be called core.autocrlf=safe
> 
> We already do half of that:
> 
>         if (action == CRLF_GUESS) {
>                 /*
>                  * We're currently not going to even try to convert stuff
>                  * that has bare CR characters. Does anybody do that crazy
>                  * stuff?
>                  */
>                 if (stats.cr != stats.crlf)
>                         return 0;
> 
> but we don't check that there are no "naked" LF characters.
> 
> So the only thing you'd need to add is to add a
> 
> 		/* No naked LF's! */
> 		if (safecrlf && stats.lf)
> 			return 0;
> 
> to that sequence too, but the thing is, having mixed line-endings isn't 
> actually all that unusual, so I think that kind of "autocrlf=safe" thing 
> is actually almost useless - because when that thing triggers, you almost 
> always *do* want to convert it to be just one way.

Sorry for the irruption in this discussion but as a potential git user 
for cross-platform development I'd like to share my experience/opinion, 
hope you don't mind.

I am investigating the use of git for our cross-platform project which 
uses svn currently. In our project, we mark manually *all* source file 
(*.h and *.cpp) with 'eol-style=native'. This way, if some editor on 
Windows added some CRLF in such marked file, svn will refuse to commit 
this file until you clean it up. This means that all C/C++/python files 
uses LF eol exclusively on all platforms. I believe this is the only 
sane way to do cross-platform development.

Now, marking any new file manually is cumbersome and some developers 
often forget to do it. I would like to be able mark all files with a 
given extension (.c, .cpp, .h) with "LF only". This way, Windows only 
files (like visual studio projects) can stay with CRLF. It would be 
fantastic if git could do that.

> 
> I've seen it multiple times when people cooperate with windows files with 
> unix tools, where unix editors often preserve old CRLF's, but write new 
> lines with just LF.

Multiple versions of Visual studio do just this indeed.

Abdel.