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
