On Jan 11, 2008, at 1:02 AM, Linus Torvalds wrote:

quoted text
>
>
> 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 ...


quoted text
> 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).


quoted text
> (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



-
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