Re: [Libusb-devel] CRLF in files checked out on Windows

[Pete B. <pb...@gm...>]

On 2010.12.06 22:31, Segher Boessenkool wrote:
> Dunno what you mean here, "two alternatives"?

* eol=lf / eol=crlf and running the risk of having it overridden and 
people not getting lf'd files if they use MSYSgit whose defaults are 
autocrlf=true, safecrlf=false, as advocated by Peter
During my tests with the supertest branch, I found that eol=lf could be 
be overridden by such settings, and Michael has also found that eol=crlf 
could be overridden depending on how you switch branches.
* -crlf and always getting these files as LF/CRLF

> People will need exactly those same settings for any other open source
> project hosted in git,

It's not because other people do one thing that we should follow suit, 
when we can fix a potential issue that they don't seem to either be 
aware of, or be willing to fix.

> Also, users who do not know this stuff are much more likely to use
> tarballs / zipfiles anyway, as has been pointed out to you a lot of
> times already.

Then you are discriminating. People who don't use tarballs can have 
problems that we know how to fix. As I said, because producing snapshots 
can take a while, people are expected to use git if they are interested 
in a feature that is not yet in a snapshot. I'd rather people be in a 
position where they can help us test libusb by using git, than have them 
wait for a tarball to identify issues.

And actually, if the tarball line ending format is the format we 
actually want, why then don't we enforce it in git? If we don't provide 
tarballs and then expect users to go through a conversion, why then 
should we provide the files from git in one format, and then expect git 
to apply some conversion.

The only files that might need conversion are the .c/.h, because we 
expect people to use them in editors that won't be able to handle a 
specific line terminator if we enforce one. This does not apply for 
.ac/.am/.sh and MS project files, as there is only ever one set of line 
terminators that should be applied to those.

Even as they are text, if we know, as we do, the line ending format that 
we want for these files, git has no business whatsoever to convert them. 
None.
So far, the only reasons for rejecting -crlf I have seen are:
- *you* don't want CR in the repo
- *you* don't want to constrain LF, even as we know that we want LF on 
some files always, as it avoids issues.

Now, and this is also the important part that you may have missed, my 
tests at the time (supertest) showed that even with eol=lf, one could 
get CRLF on the files that should be LF (.sh), and this is why I believe 
that -crlf is the only approach that will work.

I will test it again when I have a chance, just in case I got it wrong, 
but I *have* seen eol=lf fail to produce LF, the proof of that being 
that I went with -text in supertest [1] -> [2]. Had I found that eol=lf 
worked, that's what I'd have used.

This is why, no matter what Peter says, I do NOT trust eol=lf to solve 
our problem, and I do believe that people will run into problems with it 
that will not occur if we use -crlf. The only reason to reject -crlf 
right now is some wishful thinking that what I've seen in supertest was 
just a fluke, and that eol=lf does actually work always. Maybe Peter is 
confident in git's line conversion, but, from experience, I'm not, and 
as far as I know, Michael also has found reasons not to be either.

> Exactly similarly, we can limit all our source files to have lines of
> at most 40 chars, so they can be displayed on a C64;

Except nobody is expected to read our code on C64.
People are expected to want to transfer files from on env to another, 
because there is a perfectly plausible scenario for it (UNIX <-> 
Windows, with one machine not having internet access).
Oh, and I can come up with a C64 scenario if you want to go that far:

Let's say someone in an impoverished country is trying to get into 
computing, and all they have is a C64. They are very eager to learn, and 
they have heard of this very cool project called libusb, which is of 
great interest to them. Somehow they managed to get the source. Well, if 
there exists a 30 seconds fix to get 40 chars formatting, and we expect 
our user base to be OK with it (which is the only part where this 
scenario is implausible because cutting at 40 is expected to penalize 
every other user of libusb), I wouldn't see a problem in implementing 
such a fix, because it helps people exert their freedom to copy, use and 
modify the source of libusb in any way they see fit. Now if the fix 
takes much longer to implement, and/or will penalize other users by 
restricting their freedom to use the source as they see fit, of course 
it wouldn't make sense.

So far, the only person that has found any problem in going -crlf is 
Michael, but that was on CRLF files (not .ac/.am/.sh), and if you look 
at the commit that Michael failed to apply, it really looks like a git 
issue, because there's nothing in that commit that is expected to cause 
a problem that git shouldn't know how to handle: We just turn files to 
-crlf and we convert them.
As such I am confident that, if we don't convert files, as wouldn't be 
needed for official, nobody will experience Michael's problem.

And as Michael pointed out, he didn't have an issue with -crlf on .sh.

> Copying files around like that does not work, has never worked, and will
> never work.

Not when the files only need to have one type of line termination 
always. The only problem is with dumb editors, but when a file must have 
the same line terminations on all platform, then unless you are using 
ftp in text mode (bad idea - it's the same as using git to do the 
conversion for you), so copying files around does work. Again there's no 
platform I know of where a shell script doesn't need to be LF'd.

Regards,

/Pete


[1] 
http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=73bba959b695fabbe679b3754917ed919218b55d;js=1
[2] 
http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=d5032f4e537ddf5636b78238e2266261935c4b84;js=1