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

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

On 2010.12.06 15:06, Peter Stuge wrote:
> Pete Batard wrote:
>> But what I have an objection to is not enforcing files that should
>> always be LF as LF,
>
> You seem to not completely understand what I proposed earlier today.
> Please read my messages again. I believe what I suggest (text eol=lf)
> will give git users freedom to choose their line endings (using
> *crlf=true) but still ensure that special needs are met for
> autogen.sh and configure.ac.

OK, let me go with my old favourite of why I think your solution will 
not work: scenarios.

The premise here is that if a user ever gets a file that should not have 
the line endings it should have (LF for .ac/.am/,sh, CRLF for MS proj), 
it's game over. We don't know for sure that MS projs will ever be an 
issue, but one of the point of this thread is to assume so.

Scenario 1:
- UNIX developer wants to use libusb in their project (along many other 
libraries) and choses git to retrieve the source (maybe they want 
hotplug and we're in the process of integrating it, with no snapshot 
available).
- UNIX developer diligently reads our wiki pages and sees the *crlf 
advice, and our advice that he should not copy repos from UNIX to 
Windows. Since he's on UNIX and has no Windows development planned, he 
leaves *crlf off.
=> UNIX developer has MS project files with LF endings
- 6 months down the line, UNIX developer who has been successful with 
his project decides to port it to Windows MSVC. Since he already has git 
on UNIX, and installing git on Windows doesn't seem a necessity, he just 
decides to pull (he's developing so he might as well test the latest 
version) and then copy the files over. Obviously, since it's been 6 
months, he has forgotten everything about our one line advice not to 
copy repos.
=> game over

Scenario 2:
- Windows developer, libusb, git version
- diligently reads our wiki page, and applies the *crlf=true to that he 
gets CRLF'd files. If the configure.ac text eol=lf works, he is supposed 
to get LF'd files there. So far so good.
- later down the line, while using another git repo, he decides to 
change his *crlf *options* (why not - if we can advise a set of 
*options*, others can advise theirs. These are called "options", not 
"mandatory settings"), and, because he's not that familiar with git, he 
mistakenly sets them globally (as I understand from Michael, local git 
repo settings can get overridden)
- 6 months later, Windows app was successful, so now he wants to port it 
to UNIX. For now he decides to pull from libusb official on Windows to 
see the changes. Now let's say we added a new Makefile.am in the 
meantime (new samples, etc). Right now, because he modified them 
globally with that other project, he has *crlf options that may result 
in the new Makefile.am to ve CRLF'd (not sure about the old ones, so 
I'll assume they're still LF'd)
- copies to a UNIX a system (might not have internet connectivity to the 
UNIX system, so he's using an USB key), and obviously has forgotten our 
little rule about not doing so (it's been 6 months!)
=> game over

If you want to dismiss those scenarios as far fetched, fine, but we 
happen to know that we can address them both with -crlf, so really our 
choice is between:
1. preventing potential problematic scenarios that we know how to prevent
2. keeping the maintainers happy for no other reason that they...

> just do not want any CR in the repo

or use -crlf/-text and, as a result, having to make sure that our git 
users read and re-read our little rules, and have their freedom 
restricted, unless they want to waste their time.

Regards,

/Pete