Re: mingw, windows, crlf/lf, and git

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Feb 14, 2007, 20:24 UTC
Message-ID: <200702142124.10996.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.64.0702141027380.3604@woody.linux-foundation.org>

onsdag 14 februari 2007 19:31 skrev Linus Torvalds:

Show 17 quoted lines

> 
> On Wed, 14 Feb 2007, Robin Rosenberg wrote:
> > 
> > That may be why an excellent piece of software, TortoiseCVS,  doesn't trust 
> > cvs or cvsnt to do the job. Here is how they do the binary detection (and 
> > some more):
> > 
> > http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/TortoiseCVS/src/CVSGlue/CVSStatus.cpp?revision=1.172&view=markup
> 
> Well, it does seem to boil down to what Junio already got to:
> 
>  - 0-31 and 127 are never in text, except for BEL, BS, HT, LF, FF, CR and 
>    ESC.
>  - 128-255 can all be in either iso-8859 or extended ascii (or they 
>    explicitly add NEL but not 128+27 to "normal ASCII", which is strange)
>
> So they've effectively added BEL and ESC to the listof characters that

Especially ESC used to be common in DOS/Windows and quite a few hang around in older code.

> Junio has now. But they also make it an absolute error to have anything 
> else (no "1% rule").

Can this 1%-rule be motivated from real cases, rather that hypotetical ones? It makes it harder to understand why the tools makes a particular decision.

> But they also do the filename tests, and I think that's more important in 
> many ways.

A unixy tool like git should maybe use magic too :).

Btw the filename (like .gitignore or similar) test in practice would give us 
 the binary flag. Just list a filename instead of a pattern.

-- robin