From: Pete B. <pb...@gm...> - 2010-12-06 01:22:26
|
On 2010.12.06 00:55, Michael Plante wrote: > No, supertest has eol=crlf on libusb.dsw. Ah shoot! That's why it's a test branch: -crlf wasn't applied everywhere, and I only remember what I did for .sh (which was my prime concern and the goal of supertest) >>>>> $ git clone http://git.libusb.org/libusb-pbatard.git . -crlf'd .gitattributes and CRLF'd files in the repo. >>>>> $ git checkout -b prest pbr288 # pbr288 is the common ancestor .gitattribute is now gone LF'd files in repo. Disk files expected LF. >>>>> $ git checkout -b pbst origin/supertest eol=crlf in .gitattributes, LF'd files in repo, but commits from 288 to upertest latest not touching line endings and eol=crlf expected to apply on checkout only (why not?) so no conversion(?) >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows LF-only...] Expected... when you know what you want to expect and pull out some explanation out of nowhere as I did above. >>>>> $ git checkout master -crlf in .gitattributes, CRLF in the repo and. Files on disk expected CRLF... unless moving forward with the double -crlf in .gitattributes and LF -> CRLF conversion nullifies the LF -> CRLF because .gitattributes is not yet applied (which could have been your issue as well). Would work in reverse, because .gitattributes -crlf is set before reverting the commit. LF in repo? CRLF in repo? Place your bets. >>>>> $ git checkout pbst Supposed to go back to LF. Unless we were already LF git decides to silently apply the reverse of commit patch on files he has a problem with, in which case we would go through LF -> CRLF in the repo... >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows CRLF...] ...and we get CRLF here. Do I get a prize for the "most logical explanation clearly pulled out of thin air and not backed by any shred of evidence whastoever" contest? In any case, looks like a bug. Regards, /Pete |