Re: CRLF problems with Git on Win32
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Jan 11, 2008, 07:10 UTC
- Message-ID
- <7EAB1DA8-627D-455E-AA23-C404FDC615D9@zib.de>
- In-Reply-To
- <alpine.LFD.1.00.0801101556380.3148@woody.linux-foundation.org>
On Jan 11, 2008, at 1:02 AM, Linus Torvalds wrote:
Show 20 quoted lines
> > > On Thu, 10 Jan 2008, Gregory Jefferis wrote: >> >> So this is what has to be accommodated. But instead of having >> autocrlf >> always set on Windows and always converting to LF in the >> repository, why not >> do nothing by default [ .. ] > > Why? You can screw yourself more, and much more easily (and much more > subtly), by leaving CRLF alone on Windows. > > The thing is, 99.9% of all people will be *much* better off with > autocrlf=true on Windows than with it defaulting to off (or even > fail). > > Isn't *that* the whole point of having a default? Pick the thing > that is > the right thing for almost everybody?
Are you also for "autocrlf=input" as the default on Unix? This is the second half of the solution to the cross-platform problem ...
Show 12 quoted lines
> And no, "but think of the children.." is not a valid argument. > Sure, you > *can* corrupt binary imags with CRLF conversion. But it's really quite > hard, since the git heuristics for guessing are rather good. You > really > have to work at it, and if you do, you're pretty damn likely to > know about > the issue, so that 0.1% that really needs to not convert (and it's > usually > one specific file type!) would probably not even turn off CRLF, but > rather > add a .gitattributes entry for that one filetype!
... and then Windows and Unix users would have the same chance of data corruption.
Which is very low, yes, but unfortunately it already hit me once and I didn't immediately recognized what happend. I guess that less experienced git used would have a harder time to understand. However, I don't have a test case at hand. I should probably better go and find one. So for now, you may just want to ignore this comment.
Yet, I'm a bit paranoid about the potential data corruption. The way data would be corrupted during commit can't be easily fixed. You only have a chance for fixing this if you recognize the problem before you delete the file in your work tree. But because git is extremely good at preserving your data once you committed a file, I tend to feel _very_ safe after I committed and I am teaching all people that once they committed data to git they'll not loose it until the reflog expires (well and obviously they must not delete .git).
Show 6 quoted lines
> (Side note: if there are known filetype extensions that have > problems with > the git guessing, we sure as heck could take the filename into account > when guessing! There's absolutely nothing that says that we only > have to > look at the contents when guessing about the text/binary thing!)
Looking on the content seems the right thing to do. The filetype extension could be misleading.
Maybe a mechanism similar to the file command would be more valuable. I guess a stripped down variant should be sufficient.
Steffen