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

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

On 2010.12.06 01:27, Michael Plante wrote:
> 1a) I succeed.  If it didn't take long, great.  If it took a long time and
> Peter decides he doesn't like what you've done, I've wasted my time twice,
> once forward, and once reverting.

I'm pretty sure Peter will not like -crlf, regardless of whether we 
prove that your issue will not affect anybody branching off official if 
we go -crlf on project files, and that this is the safest way to ensure 
that people who clone/branch-off the official repo don't run into CRLF 
issues ever. The first thing he did when I asked him to use -crlf on 
configure.ac was to go with eol=lf instead.

> 2) we switch to eol=crlf after git is fixed (assuming it is a bug) and
> require people to upgrade...possible or not?

I don't like forcing people to use tools that have yet to be released. 
It's libtool's CJK all over again...

> Forget for a second whether we
> should reasonably expect everyone to upgrade so quickly, and just pretend we
> can require people to upgrade...

Huh, OK. :(

> would this cause any problems in libusb.git
> itself if we wait that long?  In essence, taking this option requires taking
> option 1 or 3 first, and then switching later.  Dunno if that's a bad idea.

That would rule out using #1 in the meantime, as we'd then need to get a 
CRLF -> LF conversion on all the MS project files when we switch back 
and I expect maintainers not to like such a commit one bit (whereas I 
see it as acceptable if it's to work around a bug) => we must go with #3.

> 3) we take your compromise of dropping references to .ds? in .gitattributes
> and expect people to set autocrlf (which is incidentally set for you in the
> install wizard for msysgit anyway).  Then what?  I guess that's the
> least-bad option, but I'm not sure.

Then we hope that MS environments are fine with non CRLF files (which is 
what we currently expect, so it's still reasonable), for people who 
won't have the autocrlf options they're supposed to have.
Now of course, if there's ever an issue with ____crlf and we find we 
want to go -crlf after all, we'll have a conversion commit and then we 
might find more people experiencing the same issue you had. Or we hope 
that eol=crlf is fixed when/if that happens, and can't be overruled by 
config settings...

Regards,

/Pete