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

[Segher B. <se...@ke...>]

>>> Zip can handle text vs. binary files.
>
> Yes.  But what I'm saying is that Windows users naturally go for a zip
> file
> over a tgz when available.

I think so, yes.  I'm not sure the zip files gitweb produces will do
what you want though, wrt line endings.

> Vice versa in Linux.

Maybe.  But many MacOSX users will grab the zip file.

> Right?  So no need for
> them to read instructions indicating which file to get, and they
> automatically get the right endings.  More often than 50/50, anyway.

More often than 50/50, sure.  But if _that_ is your goal, we already
have it!

I don't think the gitweb-generated tarballs/zipfiles are terribly good
for not-so-experienced users.  Never mind the line endings -- what about
autoconf and other build requirements.  Release-like snapshots are a much
more robust resource for them.

>>> I was under the impression Pete wants those files
>>> checked in with CRLF and everything, that's all I meant.  It seems to
>>> me they will work fine also if checked in as LF like everything else,
>>> but I don't care, and I don't really even want to know.
>>>
>>> "Build system" is the autoXXXX stuff, makefiles, that kind of thing.
>>> Stuff that humans can edit without GUIs ;-)
>
> They're still text.  You've already said CRLF doesn't mean binary.  Are
> you
> changing your mind?

For the umpteeth time: I don't care about those files.  For no
environment other than MSVC do they matter at all, as long as
they stay out of the way.  For anything to do with cross-platform
issues, _they don't exist_.

As I've also said at least ten times now, if you want to be sure
git doesn't mangle line endings on those files, you can check them
in as binary files.  Which would mean of course that CRs end up in
the repo -- all bytes in there do, just like if you checked in a PNG
file or whatever.  If whoever handles the MSVC project files prefers
to do it another way, that's fine with me.

>>> Wow.  Luckily libusb isn't very big, or that would take a lot of space
>>> and time to generate!
>
> That's a good point.  Keep just the last 3 or so per branch, or maybe only
> the ones that are "git tag"-ged.

I think this whole exercise would become less than useless that way.  And
I don't think it matters; libusb is very small, machines are huge and
fast these days, etc.  But I really don't care.

> Although Pete tags a significant
> fraction
> of his commits, so there might be some objection to that.

Those tags won't end up in the official repo anyway.

Maybe you want Pete to make snapshots off his tree, at least until it
gets merged?


Segher