Re: [Libusb-devel] >=autoconf-2.63 no grokmultiline AC_CONFIG_FILES?

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

On 2010.12.05 19:19, Michael Plante wrote:
> Please try the attached patch,

You mean the exact same thing that I already tried in my supertest 
branch [1] (which was dedicated to solving that issue) and which didn't 
work? Now, I must admit that my prime concern then was with the .sh 
rather than the solution files, but considering that I found that even 
with "*.sh eol=lf" my script files would be altered to CRLF, you'll 
understand that I have little confidence in eol=crlf.

Git doesn't have any business of modifying line terminators on MS 
project files, regardless of whether a maintainer/libusb developer might 
edit said files and introduce LFs in the process.
And I hear you guys say: "But wouldn't it be better if git autocorrected 
those to ensure CRLF?" Well, if we knew that the eol option worked 
always, yes, but considering that my tests at the time showed that the 
eol setting could be overridden and didn't amount to much at enforcing 
line terminations, it looks like a lesser choice compared to -crlf. 
Unlike what is the case for eol, we have no reason to suspect that -crlf 
might not work, and, as far as I am aware right now, it only introduces 
issue to people caught at the transition if we either haven't been 
careful enough to split it between .gitattributes / line ending changes, 
or if they chose not to apply the necessary line ending changes commit 
that comes with such a move.

Besides, when did protecting against clueless maintainers/libusb 
developers (NB: I'll count myself in that lot if it turns out we need to 
split commits on .gitattributes before committing changed line endings) 
become something we should strive for, while protecting against clueless 
users (whose only bad move was to clone the git repo) isn't?

Regards,

/Pete

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