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

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

> Maybe I'm missing something, but I fail to see how applying -crlf (or
> -text) on the files we care about is not exactly the solution that
> we've been wanting all along.
>
> [1] "Unsetting the text attribute on a path tells git not to attempt
> any end-of-line conversion upon checkin or checkout. "
>
> In other words: "Move over git! I'll take care of line endings myself.
> And please make sure you don't touch them.", which seems to me like
> the exact solution we want.

Checked out text files should have the line endings your OS and tools
expect, not what whoever checked them in prefers.

> All we need to do is ensure the files we care about have the right
> line endings, and it won't matter who retreives files on which OS and
> with which tools. A .dsw retreived on any platform will have CRLF
> (provided it was checked in with CRLF, which should be the case if
> .gitattributes applied at the time of checking in) and a .sh will have
> LF.

Is that really what the various POSIX(-like) environments on mswindows
expect?

> So UNIX people can package files for MS users, and life's just
> peachy.
>
> The only issue is if the same file *must* be CRLF in one environment
> and LF in another, but we have no such item.

Except all our text files, i.e. almost everything.

> Our .sh/.am/.ac must be LF in all environments,

Got proof of that?

> As to not using tools
> that can handle a specific set of line terminators, I don't think that
> is something we should concern ourselves with, so long as users always
> get the files that matter with line endings that are set in stone.

You really want to punish all unix users because some mswindows users
cannot sort out their work environment?  And you really think that is
acceptable?

I'm perfectly happy about setting whatever weird attributes on MSVC
project files, but please keep our precious shell scripts sane :-)

I also would prefer not to have to set attributes on every second
file in the repo, sigh.


Segher