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

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

Yay, let's spend our Sunday working the idiosynchrasies of git...

On 2010.12.05 23:21, Michael Plante wrote:
>>>>> $ git clone http://git.libusb.org/libusb-pbatard.git .

(Talking only about the .ds_) OK, now you have -crlf'd .gitattributes 
and CRLF'd files in the repo.

>>>>> $ git checkout -b prest pbr288 # pbr288 is the common ancestor

.gitattribute is now gone and repo should have LF'd files.

Even if .gitattributes was still valid during the branching back (very 
doubtful, but hey) -crlf would be applied, so the LF -> CRLF conversion 
would be reverted => we should have LF'd files in the repo.

No the question you also mentioned that your autocrlf/safecrlf are off, 
so from repo to disk there should be no modification => disk files are LF'd

>>>>> $ git checkout -b pbst origin/supertest

OK, now we're switching to supertest, which adds -crlf in .gitattributes 
but does NOT convert the files => still LF in the repo and therefore 
LF'd on disk.

>>>>> $ hexdump -C libusb.dsw |less
>>>>> [...shows LF-only...]

Expected.

>>>>> $ git checkout master

Back to master. Files are (expected) CRLF in the repo and -crlf in 
.gitattributes. Files on disk expected to be CRLF.

>>>>> $ git checkout pbst

Back to supertest. Again, same .gitattributes (for the files we care 
about). Now, everything I've heard about git says it goes through the 
branch ancestor internally, which is what's you've explicitly done 
above, so we should end up with LF'd files as we're supposed to revert 
master/b5820d34a.

>>>>> $ hexdump -C libusb.dsw |less
>>>>> [...shows CRLF...]
>>>
>>> If it turns out that that isn't how things are supposed to behave, then
> we have a bigger issue.

OK then we have a bigger issue, and it looks like a git bug to me. Piece 
of crap! Even when you do everything you can to logically avoid git to 
put its nose into your line endings, it finds a way to stab you in the 
back. Another nail in the coffin of trusting git with any line endings 
as far as I'm concerned.

But my guess is that, if we go with -crlf, since we'd be committing new 
files in official after any application of .gitattributes, people 
branching off official will not be affected by this behaviour since 
there would be no commit in the repo where the files are LF only.

As to trying to CRLF'ing the code (or LF'ing it), which is something you 
mentioned, I don't really see much of an issue with it, as long as the 
repo stays LF. The only issue I see are LF'd files from the repo that 
MUST not be CRLF'd ever (.sh/.ac/.am) and external CRLF'd files that the 
repo has no business to LFize (MS proj and possibly .cmd _source). Our 
.c/.h are in neither category, so whichever option you and the 
maintainers want to go with is fine by me.

Regards,

/Pete