On 2015-12-16 08:22-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Wednesday, December 16, 2015 12:59 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] git blog
>>
>> My latest "interesting" experience with git concerned line endings.
>>
>> (I ran into this issue as part of my joint work with Arjen on the new 
>> Fortran bindings
>> which we plan to merge to master a month or so before I make our next 
>> release to
>> allow plenty of time for testing.)
>>
>> Getting back to the line endings topic, by default (see
>> .gitattributes) our text files have the auto attribute which means the 
>> repository
>> version will be normalized to LF endings and the checked out versions will 
>> be native
>> line endings (i.e., LF for Unix, CRLF for Windows).
>>
>> However, I just committed (on a private topic branch) some work by Arjen 
>> that he
>> sent me in a tarball.  Those files in the tarball contained CRLF line 
>> endings.  Here is
>> what git said when I committed those (unchanged) files.
>>
>> software@raven> git commit
>> [new_f95_update 73336a7] Fortran binding: add missing files to the new 
>> binding
>> warning: CRLF will be replaced by LF in bindings/f95/plparseopts.f90.
>> The file will have its original line endings in your working directory.
>>

> Line endings cause no end of nasty little issues like this. By the
looks of the messages, git is keeping two settings per file: the way
it should go into the repository and how it should be written on disk.
I would have thought that depends only on the OS.

Hi Arjen:

It actually depends on the .gitattributes file in our repository (or
any other) which configures how line endings are treated for a
particular repository.

> Several years ago I had set my editor to save files with LF instead
of CRLF. This led to complaints from colleagues who saw these LF line
endings appear in the Windows-based repository. Every file I touched
was stored in completely new form because of this. So I turned it back
to CRLF.

CRLF is also correct for you for the PLplot repository which is configured in
the .gitattributes file to generate native line endings (i.e, LF for Unix
and CRLF for Windows) in the working directory for text files while
those files always have LF endings in the repository itself.
Furthermore (as in my early post today) git gets a bit confused if you
go out of your way to violate those working directory expectations for each
platform (i.e., if I create a text file in the working directory with CRLF or 
you create a text
file in the working directory with LF).  But the Unix tr command can
convert from CRLF to LF in a hurry so line endings are not much of a problem for
me especially when the git commit command warns me of exactly what it is
doing with line endings (in the case earlier today converting to LF
for the repository, but it warned the CRLF line endings were still
in my working directory.

> Perhaps I should take more care and send files in LF form when
bypassing the repository.

In all honesty it is not much of a problem for me to do the necessary
conversions.  However, I am virtually positive line endings will never
be an issue (so long as you stick with CRLF and I stick with LF that
are respectively appropriate for our two platforms), if we bypass the
SF repository (which we have to do with our rebase workflow to
collabarate on a topic branch) using "git format-patch"/"git am".

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to