[Numpy-discussion] whitespace in git repo

[Darren Dale]

On Wed, Oct 27, 2010 at 11:31 AM, Friedrich Romstedt
<friedrichromstedt at gmail.com> wrote:
> Hi Darren,
>
> 2010/10/27 Darren Dale <dsdale24 at gmail.com>:
>>> 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?
>>
>> "What are considered whitespace errors is controlled by
>> core.whitespace configuration. By default, trailing whitespaces
>> (including lines that solely consist of whitespaces) and a space
>> character that is immediately followed by a tab character inside the
>> initial indent of the line are considered whitespace errors."
>>
>> No mention of EOL conversions there. But yes, I guess we disagree. I
>> prefer to have git automatically strip any trailing whitespace that I
>> might have accidentally introduced.
>
> I agree.  But I just guess that the changes of the svgs in your pull
> request might be not due to eols but due to whitespace fixes.

No, it was not. I explicitly checked the svg files before and after,
using open("foo.svg").readlines[0], and saw that the files were CRLF
before the commit on my branch, and LF after.

> I think
> so because in my numpy (current master branch) I cannot see any CRLF
> there in the repo.  Checked with ``* text=auto``, which also affects
> non-normalised files in the repo.
>
> But it might be that the conversion is done silently, although I don't
> know how to do it like that.  So no "changed" showing up implies "no
> non-LF eol".
>
>>> This whitespace & newline thing is really painful, I suggest you set
>>> in your .gitconfig:
>>>
>>> [core]
>>>    autocrlf = true
>>
>> I don't think so: "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." I don't want CRLF in my working
>> directory. Did you read
>> http://help.github.com/dealing-with-lineendings/ ?
>
> Aha, this is a misunderstanding.  Somehow I thought you're working on
> Windows.  Is there then a specific reason not to use CRLF?  I mean,
> you can check it in with LF anyway.
>
> The page you mentioned is very brief and like a recipe, not my taste.
> I want to know what's going on in detail.
>
>>> and in our numpy .gitattributes:
>>>
>>> * text=auto
>>
>> That is already included in the pull request.
>
> Yes, I know.  I meant to leave the line with the eol=crlf alone.  All
> based on the assumtion that you're working with crlf anyway, so might
> be wrong.
>
>>> 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?
>>
>> Check what?
>
> My conclusions above.  We both know that in this subject all
> conclusions are pretty error-prone ...
>
>>> I was near to leaving a comment like
>>> "asap" on github, but since this is so horribly complicated and
>>> error-prone ...
>>
>> I'm starting to consider canceling the pull request.
>
> At least we should check if it's really what we intend.
>
> I understand now better why at all you wanted to force the .nsi.in
> file to be crlf.  From your previous posts, i.e. that it would be the
> default for Win users anyway, I see now that I should have asked.
>
> To my understanding the strategy should be two things:
> 1)  LF force in the repo.  This is independent from the .nsi.in thing,
> but missing currently in the official branches.  We can do that at the
> same time.
> 2)  Forcing the .nsi.in file to be crlf in the check-out (and only
> there) at all times.  There is one higher level in $GITDIR, but I
> think we can ignore that.
>
> To (1): The default Win user would check-in *newly created* files
> currently in CRLF, at least this is what I did with a not-so-recent
> git some time ago (other repos) .... When I switched to Mac, all my
> files were marked "changed".  afaik git does not do normalisation if
> you do not tell it to do so. "While git normally leaves file contents
> alone, it can be configured to normalize line endings to LF in the
> repository and, optionally, to convert them to CRLF when files are
> checked out." (http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html)
>  I still do not understand why my files showed up changed.  They're
> still crlf, I just copied them, and vim tells [dos].
>
> Please also confirm or show that I'm wrong with my observation of LFCR
> in your .nsi.in file instead of CRLF (it's swapped).

I thought this was already settled. OK, on my whitespace-cleanup
branch, I modify .gitattributes to comment out the line about the
nsi.in file. I check out the nsi.in file from HEAD, and:

In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0]
Out[1]: ';--------------------------------\n'

Then I do git checkout HEAD^
tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in :

In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0]
Out[1]: ';--------------------------------\r\n'

CRLF, not LFCR.

> I checked as
> written before.
> http://article.gmane.org/gmane.comp.python.numeric.general/41063.
> This would also explain how it can make it into the repo (i.e.,
> succeed in :-) and still be not detected by git when ``* text=auto``
> is active.  Git thinks it's \n since theres no \r before, and does not
> consider the \r which is trailing.
>
> Best wishes,
> Friedrich
>
> P.S.: Might be worth putting this OL, I believe noone besides us is
> interested.  If you agree.

I'm losing interest myself. I don't think the issue is so complicated,
there just seems to be a lot of confusing misinformation being posted
here.