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

[Michael P. <mic...@gm...>]

Pete Batard wrote:
>> if they use MSYSgit whose defaults are
>> autocrlf=true, safecrlf=false, as advocated by Peter

Two different things.  Yes, those are defaults, no they are not advocated by
Peter.  Peter said to use safecrlf=true on Windows (at least to you, Orin,
and me).


>> 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

To be clear, I have no reason to believe this is necessarily a consequence
of eol=crlf.  It may well be that all .gitattributes are broken in this way,
including -text.  Unfortunately, it'd take time to come up with a test of
this.



>> > 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.

I don't necessarily agree/disagree with Segher here on the whole.  However,
this whole "let's do what everyone else does" mindset is slightly annoying.
Particularly since that eol attribute was only introduced in May, it seems.
Maybe no one else has bothered to follow up on new features (having had this
discussion when different features were available), or maybe no one else
cares enough, or maybe no one else has the same priorities, or maybe they
were using a different VCS and that affects things in some way.

Let's make the decision ourselves, rather than copying someone.  It's of
course fine to learn from others' tricks and tips, but evaluate rather than
blindly copy.


>> Segher wrote:
>> > 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.

And this could be the snapshot solution.  LF in tarballs, CRLF in zipfiles.
Slightly more work writing the script, but not too bad?


>> And actually, if the tarball line ending format is the format we
>> actually want, why then don't we enforce it in git?

That was initially my point in even suggesting that CRLF be forced even when
autocrlf is off.  I am perfectly fine expecting git users to set autocrlf
properly, but I think that the snapshot needs to be configured properly.  If
Peter (the eventual script author, afaik) would prefer to unix2dos files,
rather than messing with eol=crlf in .gitattributes, that suits me just
fine.  But I'd like to see one or the other.

The eol=lf for .sh/.ac is a completely separate issue, and one that I think
only Segher and Xiaofan think doesn't need to be solved.  Pete seems to
prefer -text, and everyone else, eol=lf.

But eol=lf is motivated by a bug in autotools and bash, rather than by
convenience.  The crlf snapshot thing is motivated by ease of use.


>> If we don't provide tarballs and then expect users to go through a
conversion,

Are tarballs or integration a higher priority to you?  Because it sounds
like Peter is responsible for both.  I don't know how many people have a
similar-enough setup to Peter to be able to help with snapshot
script-writing, and my bash skills are not all there.


>> 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.

As discussed elsewhere with Segher, I'm not aware of a modern utility that
fails to handle CONSISTENT line endings, except perhaps a problem with
regular expression matching.  Even "more", which nobody uses anymore, seems
to work fine for me, as I pointed out.  Mixed line endings within a file,
and comparing a LF file with one that uses CRLF may be a problem for a lot
of programs.


>> 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.

If it can do it right, and it makes things more compatible in terms of
working around apparent git problems, why not?


>> 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.

We may have to re-run that test, though.  Perhaps push a temporary branch
that has those files moved to a different directory.  Switch to that branch,
then switch back to supertest and see if it works.  That's my theory as to
what happened with the msvc files, given that libusb.dsw is in a different
directory in your master than in pbr288 and supertest.


>> 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.

Well, I'm confident that IF it decides to do the conversion, it does it
right.  git's lazy evaluation of .gitattributes worries me (assuming that's
what the problem is, and that's just my theory...the raw evidence is farther
back...I'd love to hear an alternative theory).


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

But I also don't necessarily have a problem with eol=lf.  We need more
testing.  See what I suggested about a branch above.


>> ask ALL our users to upgrade their git to a version that
>> is less than 6 months old...

That commit I identified is just under 7 months old, so yes.

Regards,
Michael