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

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

(forgot reply to list on this one)

On 4 December 2010 17:22, Michael Plante <mic...@gm...> wrote:
>>> 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.
>
> Assuming it obeys your wishes.  Are you sure it does?

Been using it for months now on libwdi and libusb. Haven't seen any
evidence of files being converted back by git.


>>> .dsw/.dsp/.vcproj/.sln must (should?)
>
> Don't know which, either:  must vs. should.  I haven't bothered to try them
> with LF.

Same here. Preferred to be safe and anticipate issues (especially if
snapshots are built on Linux), and being in control of line
terminators on these files, rather than leave git do whatever it
decides to do for reasons that you need to spend hours to figure out,
sounds like the better deal to me.

>>> will just see "\r" as an extra character at the end of the line (see
>>> [2] for an example), which is absolutely fine.
>
> It seems not to be "absolutely fine", because it is causing git headaches
> for me.  git diff and git status don't work right.

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.

>>> Michael, what happens if you clone my directory from scratch?
>
> What do you expect to happen?  I just tried it and it cloned (I have
> system-wide-enabled auto&safecrlf).  So what?  I can also go into my repo
> and say
>
> $ git checkout -b pm pbatard/master

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

> and that also works.  My problem comes when I try to mix with my branches
> (i.e., collaborate, rather than ONLY checking your code out and using
> as-is).

Again, the only problem is that we took measures against git's
incomprehensible handling of line terminators in the middle of the
game, and if you don't apply the same .gitattribute to your branches,
and convert the files that need to be converted, you will have issues.

I still see it as a better deal than the alternative, as you're the
only one affected, and I'm pretty sure you can fix it easily. I'm not
planning to add new files to gitattributes any other month. The
.ac/.sh/.am were added because they were causing an issue, and the MS
proj to be on the safe side. In all likelihood, this is a one off
operation, that will ensure that anybody who branches from libusb in
the future will not have to waste their time with terminations. Yeah,
this was bad for you, but that's one against all our future
contributors, and, AFAIK, if you understand what happened, you should
be  able to fix your branches.
You'll have to recommit converted files, but I don't see it as a big
deal on private branches.

Also, merging the planned .gitattributes into mainline won't be an
issue (as the MS proj files are not there yet, and the others are
already LF'd).

Regards,

/Pete