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.

And so forth for the remaining files he sent me in the tarball.

The repository version is LF (which is good), but I was concerned
about those CRLF files still in my working copy which are not
equivalent to the LF versions that would normally be checked out on my
platform to my working copy from my local repository.  For example, I
could conceive of a scenario where "git rebase" might run into trouble
for my local topic branch due to this issue with my local working
copy.

Accordingly, I changed to bindings/f95 in my working copy where these
files are all located and used

for FILE in *; do echo $FILE; tr -d $'\r' <$FILE >/tmp/$FILE; mv -f /tmp/$FILE 
$FILE; done

to transform my checked out file versions from CRLF to LF.

After that working directory change, "git status" claimed the files
were changed.  However, when I used "git add" for those files
the "git status" result turned into

On branch new_f95_update
nothing to commit, working directory clean

That result makes a lot of sense since my local changes to convert
CRLF to LF were exactly consistent with the expected native checked
out result so there was nothing to commit (once I had used "git add").

Furthermore, I looked for any other instances where my working directory
might not be consistent with the expected native treatment of line endings
using

git check-attr --all $(find . -type f |grep -v .git |xargs grep -l $'\r') |less

and in all cases, the files containing $'\r' (i.e., a carriage return
character) were all binary files with the attribute "text: unset"
which is confirmation that we have properly identified the binary
files in .gitattributes where line ending manipulations should not be
done.

So the conclusion is our git repositories are set up by our
.gitattributes file in a way that is smart about native line endings
for both text files and binary files, but potentially you could create
some line ending trouble (just for your local working directory since
this issue cannot propagate to your local repository or anywhere else)
if you copy by non-git means (e.g., via a tarball) files with
non-native line endings to your working directory and you don't fix
that situation (as I did above with the tr command for this particular
instance).

I am virtually positive that if Arjen had sent me his work as local
topic branch commits that he had formatted with "git format-patch",
then the line endings would not have been an issue when I applied his
commits to my own local topic branch using "git am".

So this is yet another reason to use "git format-patch"/"git am" to
communicate private topic branch work between our developers who are
collaborating on a topic that is not yet mature enough to qualify to
be committed to the master branch.

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