On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris <[email protected]> wrote: > > > On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale <[email protected]> wrote: >> >> Hi Chuck, >> >> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris >> <[email protected]> wrote: >> > >> > I'd like to do something here, but I'm waiting for a consensus and for >> > someone to test things out, maybe with a test repo, to make sure things >> > operate correctly. The documentation isn't that clear... >> >> I am getting ready to test on windows and mac. In the process of >> upgrading git on windows to 1.7.3.1, The following dialog appeared: >> >> Configuring line ending conversions >> How should Git treat line endings in text files? >> >> x Checkout Windows-style, commit Unix-style line endings >> Git will convert LF to CRLF when checking out text files. When >> committing text files, CRLF will be converted to LF. For >> cross-platform projects, this is the recommended setting on Windows >> ("core.autocrlf" is set to "true") >> >> o Checkout as-is, commit Unix-style line endings >> Git will not perform any conversion when checking out text files. >> When committing text files, CRLF will be converted to LF. For >> cross-platform projects this is the recommended setting on Unix >> ("core.autocrlf" is set to "input"). >> >> o Checkout as-is, commit as-is >> Git will not perform any conversions when checking out or committing >> text files. Choosing this option is not recommended for cross-platform >> projects ("core.autocrlf" is set to "false") >> >> This might warrant a very brief mention in the docs, for helping >> people set up their environment. Its too bad core.autocrlf cannot be >> set on a per-project basis in a file that gets committed to the > > Yes, this would be good information to have in the notes. > >> >> repository. As far as I can tell, it can only be set in ~/.gitconfig >> or numpy/.git/config. Which is why I suggested adding .gitattributes, >> which can be committed to the repository, and the line "* text=auto" >> ensures that EOLs in text files are committed as LF, so we don't have >> to worry about somebody's config settings having unwanted impact on >> the repository. > > Might be worth trying in a numpy/.gitconfig just to see what happens. > Documentation isn't always complete. >> >> And now the bad news: I have not been able to verify that Git respects >> the autocrlf setting or the eol setting in .gitattributes on my >> windows 7 computer: I made a new clone and the line endings are LF in >> the working directory, both on master and in my whitespace-cleanup >> branch (even the nsi.in file!). ("git config -l" confirms that >> "core.autocrlf" is "true".) To check my sanity, I tried writing files >> using wordpad and notepad to confirm that they are at least using >> CRLF, and they are *not*, according to both python's open() and grep >> "\r\n". If it were after noon where I live, I would be looking for a
maybe just something obvious: Did you read the files in python as binary 'rb' ? I checked two old git checkouts (with a one and a half year old git version), pymvpa and scikits.talkbox and both have files with \r\n as line endings on my windowsXP. I don't think I did anything special, but maybe I had used a GUI interface for those. Josef > > Grepping for CR is tricky. The straightforward way is grep ctrl-v ctrl-m. > I'm pretty sure notepad uses CRLF since it doesn't do line breaks for "unix" > text. > > >> >> bottle of whiskey. But its not, so I'll just beat my head against my >> desk until I've forgotten about this whole episode. >> _ > > Oh, don't do that. Someone's got to explore the territory and, as an > official old fart, I'm volunteering the younguns. > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
