[Numpy-discussion] whitespace in git repo

josef.pktd at gmail.com josef.pktd at gmail.com
Thu Oct 28 12:23:27 EDT 2010


On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale <dsdale24 at gmail.com> wrote:
>>
>> Hi Chuck,
>>
>> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris
>> <charlesr.harris at 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 1.7.3.1, 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

maybe just something obvious: Did you read the files in python as binary 'rb' ?

I checked two old git checkouts (with a one and a half year old git
version), pymvpa and scikits.talkbox and both have files with \r\n as
line endings on my windowsXP. I don't think I did anything special,
but maybe I had used a GUI interface for those.

Josef

>
> 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"
> text.
>
>
>>
>> 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.
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>



More information about the NumPy-Discussion mailing list