On 2014-10-03 10:54-0700 Alan W. Irwin wrote: > In sum, I think you should change the .gitattributes file to > > *.sh eof=lf > *.sh.in eof=lf > > If I am right, (i.e., the result works for you) please commit that > change.
Also, I just noticed for your other commit that the line endings for plplot_test/CMakeLists.txt had all been changed. So I did the above changes (which you should test) and also *.txt test=auto *.cmake test=auto test=auto keeps LF in the repository and native line endings on checkout which is what you want for all text files (see additional topic introduced below). Then following the directions in the gitattributes man page about the steps to be taken (rm .git/index, etc.) to force a change in .gitattributes on existing files in a working directory and repo, it caught not only your recent change to plplot_test/CMakeLists.txt but also one *.cmake file where the incorrect non-LF line endings had gotten into our repo (probably in the svn era). In the subject line I asked you to READ THIS FIRST because this mostly supersedes my previous post on this subject. In sum, please test that my .gitattribute changes work for you. To add one additional line-endings topic to this conversation, the above change for *.txt files and *.cmake files is obviously too specific. Instead, we should be using * text=auto as the first line of the .gitattributes file so this generic rule could be superseded by more specific rules later in the file (e.g., for *.sh and *.sh.in) when required. The motivation for this change is to make sure there are no further line-endings issues introduced into the repository. This pattern insures LF in repository and native (LF or CRLF) in working directory for all files which git decides are text files. This is generally what we want (except for the *.sh and *.sh.in exceptions) for all text files. With this pattern, you can happily make changes to any text file with your Windows editor and not worry that you will change the LF endings in the repo or for any Unix user that checks out the result. And vice versa for Unix users making changes. There is a caveat to using "* text=auto" which is whether git detection of binary versus text file is good enough. So I will probably accompany this change with a few other known following patterns such as *.png -text to insure git makes no mistakes concerning line-ending conversions on the patterns like *.png that specifically identify binary files in our repository to git. So you should expect to see another commit from me along these lines (which will also check for and remove any line-endings issues that might have gotten into any of our text files since we adopted git.) But this change will be accompanied by a warning that our Windows developers should comprehensively test the result to make sure that the combination of git binary file detection and specific rules (such as *.png above) does not allow any binary file in our repo to be clobbered (by line ending manipulations) when checked out on Windows. 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 __________________________ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
