[Numpy-discussion] whitespace in git repo

Friedrich Romstedt friedrichromstedt@gmail....
Wed Oct 20 05:12:42 CDT 2010

2010/10/20 Charles R Harris <charlesr.harris@gmail.com>:
> [...] I think we do need a
> .gitconfig file [...]


> so why don't you go ahead and make one and
> deal with the nsi.in file in the process.


> The .svg files can have their line
> endings converted to line feeds

Is there anything I've missed or am I right with that currently there
is *no* policy for other files at all how they are
checked-in/checked-out.  We could setup .gitattributes to include also
.py files to be LF only by ``eol=lf`` in .gitattributes for ``*.py``,

Currently I think it works because git does not change to system
strategy by default.  But I have a dim memory about git checking in
with LF by default too, I need some pointer here I guess.  IIRC git
checks in with LF but does not change on check-out?  Due to Darren's
config file the .nsi.in file made it with CRLF into the repo.

I guess .gitattributes has precedence over ~/.gitconfig.  Pros of *.py
in .gitattributes:

*  We are independent by overriding the user's global config.  All
*.py files will be checked in with LF.


*  They'll also be checked-out with LF, wich may be annoying esp. for
Windows users.

Is there any way to force check-in LF *only*, via .gitattributes?

> [...] which will give us two less files to worry
> about.

I'm not quite sure, by analogy to .ps, where I messed up my ps files
by converting their line ends.  No tool was able to read them any
longer, seems like being included in the ps specs, maybe the same
holds for svg?  Not all software has universal eol support.  (This was
on Windows)

Darren, your specs used by you are working due to
backward-compatibiltiy of git, see
``eol=...`` is according to that doc preferrable.

Maybe I'll add ``*.dmg -text`` to prevent normalisation of the dmgs
I'd like to connect with the numpy commits in my repo.  I'll send
discussion of this in another thread later.  Since it's not approved
so far I do not add right now.

So far,

More information about the NumPy-Discussion mailing list