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.
Now that I understand the situation a little better, I don't think we would want such a .gitconfig in the repository itself. Most windows users would probably opt for autcrlf=true, but that is definitely not the case for mac and linux users. I've been testing the changes in the pull request this morning on linux, mac and windows, all using git-1.7.3.1. I made a testing branch from whitespace-cleanup and added two files created on windows: temp.txt and tmp.txt. One of them was added to .gitattributes to preserve the crlf in the repo. windows: with autocrlf=true, all files in the working directory are crlf. With autocrlf=false, files marked in .gitattributes for crlf do have crlf, the other files are lf. Check. mac: tested with autocrlf=input. files marked in .gitattributes for crlf have crlf, others are lf. Check. linux (kubuntu 10.10): tested with autocrlf=input and false. All files in the working directory have lf, even those marked for crlf. This is confusing. I copied temp.txt from windows, verified that it still had crlf endings, and copied it into the working directory. Git warns that crlf will be converted to lf, but attempting a commit yields "nothing to do". I had to do "git add temp.txt", at which point git status tells me the working directory is clean and there is nothing to commit. I'm not too worried about this, its a situation that is unlikely to ever occur in practice. I think I have convinced myself that the pull request is satisfactory. Devs should bear in mind, though, that there is a small risk when committing changes to binary files that git will corrupt such a file by incorrectly identifying and converting crlf to lf. Git should warn when line conversions are going to take place, so they can be disabled for a binary file in .gitattributes: mybinaryfile.dat -text That is all, Darren _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
