[Numpy-discussion] whitespace in git repo
Sat Oct 30 08:54:20 CDT 2010
On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris
> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale <email@example.com> wrote:
>> Hi Chuck,
>> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris
>> <firstname.lastname@example.org> 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 188.8.131.52, 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-184.108.40.206. 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:
That is all,
More information about the NumPy-Discussion