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

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

Pete Batard wrote:
>> Yes, because we addressed the CRLF/LF issue late in the game, so
>> obviously, if you already have a branch that didn't have
>> .gitattributes, you will suffer until you convert the files. None of
>> the source files should have been affected, because we didn't modify
>> how git decides to mangle them in any way.

Except that, like I mentioned, I tried for several hours to convert them and
get git to accept them.  It would not.  Since safecrlf is the only
potentially-relevant setting of mine that differs from yours, I'm guessing
that that may be the culprit.  But I'm reluctant to turn it off until I hear
what Peter has to say about the pros of safecrlf.


>> What I was asking is: do you see CRLF on MS projs, and LF on .sh (and
>> soon .ac/.am as well).

When I clone your repo, autogen.sh has LF's, libusb.dsw has CRLF's.  Ok?
I'm not sure that was ever a problem.  (Just FYI, and I don't really care,
but that stands in contrast to my working copy of libusb-mplante.git, where
everything is CRLF.)


>> I'm pretty sure you can fix it easily.

See above.  I tried in August to fix it as soon as you pushed it.  No luck.
Unfortunately, I don't remember the details, and I don't have time to go
through that exercise again (unless I'm somehow forced to, which is a choice
that's ultimately up to the maintainers).  I'm also don't see why it would
succeed where it failed the first time.  I guess I can try upgrading msysgit
first.


>> the MS proj to be on the safe side.

And these are the only files that are giving me trouble (they are the only
CRLF-only ones in your repo right now).  The files you've marked LF-only do
not give me any trouble.  The files you've marked CRLF-only do.  I'd like to
figure out why, because I really do think the files you marked CRLF-only
should be CRLF only (i.e., I agree in principle)...it just doesn't work
right for me, as described previously (on and off list).


>> Yeah, this was bad for you,

present:  is.  not was.


>> You'll have to recommit converted files, but I don't see it as a big
>> deal on private branches.

My recollection is that I tried to go back to the beginning, make the
change, and rebase on top of it.  But my memory is shaky four months later.
It was something like that.  I sure don't want all diffs across one commit
to show everything changed (when it's not really).

And why are private branches less of a big deal?  (I think they're actually
slightly MORE of a pain, but I won't bother you with the details, because
the details are not really relevant to the discussion -- my point in this
paragraph is precisely that private/public is a bit of useless trivia that
has no substantive bearing on the matter.)

Michael