From: Pete B. <pb...@gm...> - 2010-12-06 00:41:22
|
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 |