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

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

On 2010.12.06 12:51, Peter Stuge wrote:
> Pete Batard wrote:
>>> CRLF in the repo is unacceptable
>>> since git has the ability to handle
>>> conversion for us as neccessary
>>
>> Very confusingly, as this thread has shown.
>
> Then read it again. Or just follow suggested advice by someone who
> has spent more time learning about what git does and when.

And consistently dismisses libusb users that are expected to be new to 
git as people not worthy of our consideration.

>> Why would we ever want to help people who don't see getting
>> overly acquainted with git as a productive use of their time?
>
> This makes no sense. When we have learned what we need to understand
> the problem we can give simple advice about how to successfully work
> with the codebase.

Yes, because people ALWAYS thoroughly read wikis and stuff of course. 
Seriously, if we went with all your proposals, we'd have the following 
list of requirements before someone can even start to do anything with 
libusb:
- you must have libtool that is less than 6 months old (and would have 
had to be -3 months old or something if we had completed integration in 
early 2010)
- you must not use multilib MinGW-w64 ever
- you must use the exact following options if you clone from git
- you are not supposed to clone from git ever if you're really serious 
anyway, but instead use snapshots
etc...

It's very easy to place demands on people, and blaming them for not 
respecting them, when you're the one making those demands. Freedom to 
use the software in any way you want? Not so much with libusb when it 
places demands that CAN be avoided.

> Currently that would be:
>
> if you are OK with LF in your worktree: don't set any options
> if you want CRLF: set safecrlf=true+autocrlf=true
>
> Done.

And if you want to ensure that ANYBODY who clones your tree gets CRLF'd 
files, *no matter what*, you can't. I could even go as far as enforce. 
With -crlf, we can enforce that ANYBODY who clones the tree gets CRLF'd 
files if we say they should be CRLF'd. With your proposal, not so much, 
since they must first "ensure" that they have the right ___crlf.

>>> and it is very helpful to have a rule
>>> without exceptions for this,
>>
>> How so?
>
> Consistency helps a lot for dealing with a codebase.

"\r"

Enough said.

>> at the expense of git newcomers getting files with improper line
>> terminations.
>
> The tool we use is git, if people want to work efficiently with us
> then I think it is reasonable to expect that they learn a little git.

Not when we have an alternative of NOT having to force them to learn.

If git was that smart, nobody should EVER have to care about CRLFs, and 
this is what I am advocating. Ensuring that nobody has to care about 
learning about CRLF options in git who doesn't have to.

> Another benefit from consistent LF and nothing else in the repo is
> that no such conversion can happen.

Except when git checks in or checks out.
The actual "no such conversion can happen" stance is when you have the 
files in the right mode in the repo.

> Do you seriously consider it a problem to push and then pull, in
> order to do that testing? Really?

As I explained, if need to push a change on my public repo before I can 
pull it to test it on Linux, and then find that my change breaks Linux, 
you'll get another "oops!" commit.

So there's only 2 choices there. Have a private repo (but even then, I 
need to merge oops so that they appear as a single commit on public) or 
copy my files from Windows to Linux when I want to test them.

But of course, since you don't test Windows in the first place, it is 
perfectly acceptable to you to place yet another set of demands on 
Windows developers.

Regards,

/Pete