[Numpy-discussion] whitespace in git repo

[Friedrich Romstedt]

Hi Darren,

2010/10/19 Darren Dale <dsdale24 at gmail.com>:
> I have the following set in my ~/.gitconfig file:
>
>    [apply]
>        whitespace = fix
>
>    [core]
>        autocrlf = input
>
> which is attempting to correct some changes in:
>
> branding/icons/numpylogo.svg
> branding/icons/numpylogoicon.svg
> tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in

Here an excerpt from git-config:

core.autocrlf

    Setting this variable to "true" is almost the same as setting the
text attribute to "auto" on all files except that text files are not
guaranteed to be normalized: files that contain CRLF in the repository
will not be touched. Use this setting if you want to have CRLF line
endings in your working directory even though the repository does not
have normalized line endings. This variable can be set to input, in
which case no output conversion is performed.

>From git-apply:

``fix`` outputs warnings for a few such errors, and applies the patch
after fixing them (strip is a synonym --- the tool used to consider
only trailing whitespace characters as errors, and the fix involved
stripping them, but modern gits do more).

So I think your "autocrlf=input" makes the .nsi.in file checked out as
LF since it's in LF in the repo, and "no output conversion is
performed" due to core.autocrlf=input in your .gitconfigure.

So the svg changes must come from the 'fix' value for the whitespace action.

I don't think it is a good idea to let whitespace be fixed by git and
not by your editor :-)  Or do you disagree?

This whitespace & newline thing is really painful, I suggest you set
in your .gitconfig:

[core]
    autocrlf = true

and in our numpy .gitattributes:

* text=auto

while the text=auto is more strong and a superset of autocrlf=true.

I came across this when trying if text=auto marks any files as
changed, and it didn't so everything IS already LF in the repo.

Can you check this please?  I was near to leaving a comment like
"asap" on github, but since this is so horribly complicated and
error-prone ...

Friedrich