[Numpy-discussion] whitespace in git repo

[Friedrich Romstedt]

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