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

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

On 2010.12.07 16:43, Segher Boessenkool wrote:
> Yes, mswindows developers do have to consciously decide what to set
> autocrlf to.  This can be seen as a shortcoming of git; it is nothing
> we can do anything about.

I think I proved otherwise. With my current branch, nobody has to 
consciously decide how they should set autocrlf. It only matters if they 
want to push patches back to us (and then we can tell them what to use - 
this is what happened to me when I started pushing patches), which only 
concerns a very limited subset of libusb users.

> People just have to learn to use their tools.

Agreed. But we can also avoid them learning more than they should. Not 
everybody wants to be an expert on git CRLF conversion, or tax returns, 
or whatever you are being constrained to learn because you're not given 
any other choice. I don't think we'll ever avoid the need to learn tax 
returns, but we can spare the requirement of learning git CRLF 
conversion from top to bottom where a quick "if you're on Windows and 
want to submit patches to us, use autocrlf. And if you patch 
.ac/.am/.sh, please keep the files LF'd - but git will tell us if you 
introduce CRs there anyway)

> Any kludges you can come up with to make things "magically work" will
> in the end just magically explode in your face (and worse, in the face
> of people who have nothing to do with the "problem" in the first place!)

And so we've come to this. "I don't like your *solution*, and I cannot 
find a default with it on logical grounds, so I'll just call it a 
'kludge' and dangle the idea of *potential* *future* problems that I am 
unable to elaborate on, and that, had I analysed the solution properly, 
would know are not going to happen"

The only potential issue is mixing CRLF in LF files, which we can spot 
and/or fix, and which is not going to make thing "magically explode" in 
anybody's face.

If you want to reject the solution, that's fine. That's your executive 
right. But don't pretend that you are rejecting it on technical grounds, 
or do provide a potential scenario where you expect using -crlf on 
.sh/.ac/.am will effectively break things in the future.

Until then, I'll take the *proven* 3 different scenarios that I 
experienced of non -crlf breaking things for LF files (one for each of 
.sh, .ac, .am, which, since I have seen failure to convert on eol=lf I 
am entitled to assume would have happened with eol=lf as well) over your 
"future blow up" any time.

Why should my 3 *actual* "blow ups" have less importance than your 
future potential unproven "blow up"?

Regards,

/Pete