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

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

Pete Batard wrote:
>> But when I suspected that MOST Windows contributors will be affected,
>> it cannot be reduced to a simple view of "you're the only one affected
>> - big deal"

You suspected.  But then you said precisely that to me.  Why is your case different from (better than) mine, particularly when you're not using the recommended safecrlf setting?


>> and keeps a mix of branches that have
>> conflicting settings

NOT by my choice.  You made that choice for me.


>> and then complain that the *EXPERIMENTAL* branch
>> is not stable.

Just to be clear, the "EXPERIMENTAL" branch is pbatard/master, right?  If so, then daniel/master will also contain "experimental" code when (if) it's integrated, right?


>> They didn't manage to fix the problem they saw after
>> they switched, and we (or at least I) have good reason to believe that
>> only one individual will only ever be affected. 

Until Peter catches up, it's just you and me actually pushing Windows changes to git.  (And primarily you...I don't mean to shortchange you here.)  To extrapolate from a 50/50 situation seems a bit premature.  Also don't misunderstand this:  I understand that Graeme, Orin, and others have contributed significant amounts of code, but the relevant distinction to the argument is that it wasn't tied to maintaining a long-standing git repo.  So it's 50/50 so far.  

We both have autocrlf turned on, something warned about in the kerneltrap thread you cited.


>> The only files that are causing an issue, as pointed out by Michael,
>> are the MS project files. Those are CRLF. And Michael himself pointed
>> out that he had no issue with the LF'd file, which is exactly what I
>> expected.

And to clarify further, the problem lies not with MSVC itself, but with the way they're treated in git.  While I haven't tried loading them into MSVC with LF endings, I wouldn't be surprised if that works.  Nevertheless, I prefer CRLF for them.  But then the same issue would arise for all the other text files I listed, but that have not yet had .gitattributes lines added in libusb-pbatard.git.


>> because they are using
>> branches that have different settings.

Not exactly.  I have one set of settings.  My git branch that tracks yours has a different set, as of relatively recently, and not by my choice.  I.e., it is your branch that changed.


>> so things can change and/or break,
>> and unless you can prove that your issue will be carried over into
>> official (and I just explained why it won't), 

If you're right, then this problem will only persist until integration of the relevant files is complete.  When will that be?  It sounds like things will be a pain until then...


>> => only ONE user affected. 

And only ONE unaffected.  I suppose the third test case in this entire exercise will be to see if Peter is affected.


>> "oh it works - let's not explore
>> it further" but "it works, and I know exactly why it should work, and
>> how it is not expected to cause further problems when integrated into
>> official, so there's no need to waste more time on it"

Well, there is precedent...  I find it curious that we're telling git to keep hands off, rather than just telling it what the line endings SHOULD be.  Do you think doing it that way would fix things?


>> But sure, as always, our time is a lot more
>> valuable than the time that's going to be wasted by ALL those guys.

How ironic of you to say that here.

....

I guess I'll close with one other option:  turn off all such options in .gitattributes related to CRLF files and enable autocrlf/safecrlf, but ensure that Peter will unix2dos all files of interest in the snapshots.  Keep the .gitattributes related to LF files.  Would that work?

Michael