[Numpy-discussion] whitespace in git repo

Charles R Harris charlesr.harris@gmail....
Thu Oct 28 11:11:51 CDT 2010

On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale <dsdale24@gmail.com> wrote:

> Hi Chuck,
> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris
> <charlesr.harris@gmail.com> 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, 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

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"

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20101028/d4e4bc95/attachment.html 

More information about the NumPy-Discussion mailing list