Re: mingw, windows, crlf/lf, and git
- From
Sam Ravnborg <sam@ravnborg.org>
- Date
- Feb 14, 2007, 16:47 UTC
- Message-ID
- <20070214164735.GA28359@uranus.ravnborg.org>
- In-Reply-To
- <Pine.LNX.4.64.0702140823220.3604@woody.linux-foundation.org>
On Wed, Feb 14, 2007 at 08:28:24AM -0800, Linus Torvalds wrote:
Show 15 quoted lines
> > > On Wed, 14 Feb 2007, Sam Ravnborg wrote: > > > > > (Which means that I suspect I made the default for "auto_crlf" be wrong in > > > my patch: I probably should not default to checking out with CRLF, but > > > checking out with just LF, and only do the CRLF->LF conversion on input). > > > > Expect that it seems a few br0ken programs yet does not support LF as > > end-of-line marker - so .gitattriutes make take special care here. > > Yes, but I also think that even without .gitattributes, you just want to > have a default for what "text" actually means, and it's entirely possible > that the default should be: "check out with just LF, and on check-in turn > CRLF into LF".
The definition of what is "text" and what action to take upon check-in / check-out of text is two sepearate things.
I could see it as beneficial as a per-project or even as an overall git-policy to say "checkin-as-LF" - "checkout-as-LF" to overcome interoperability issues when more tools gets UNIX* based.
> > But exactly because _some_ programs might want to always see CRLF on input > too, it should be overridable.
Which is where I see .gitattributes come into play. -> A rule that says files with extension .prj and of type "text" shall not see any conversion.
In this way almost all "text" over time get a proper format and the remaining brain-dead tools that continue to save in CRLF format will not destroy the sane LF format.
If anything gets defualt I would vote for LF. But overrideable.
My editor-of-choice does eol auto-sense. If I recall correct it scans the first 200 lines and counts number of CR,LF,CRLF and based on this judge the actual eol character used. But not all editors are that sensible :-(
Sam