On 2015-12-21 08:29-0000 Arjen Markus wrote: > Hi Alan, > >> I tried that on my current working directory and private branch: same >> messages as before. I will try the "fresh start" approach later. The curious >> thing is that it also produces error messages on files that I have not >> changed in any way for this branch. These files are being moved to a >> temporary "old" directory. Oh well, let's wait for the "fresh start" >> approach to either work or fail. > > The fresh start did the trick, but to my surprise the line endings in this > completely fresh working directory are LF!
> What the reason, the most important thing is that this worked. Hi Arjen: I too am really glad the process is working for you now, but I am also just as startled as you were by your discovery of an LF working directory. Therefore, I would appreciate you systematically investigating this question further so we can draw some definite conclusions with regard to other attempts at Window/Unix communications via "git format-patch"/"git am" results. 1. Just to double check your LF conclusion above, do you also get LF for the text files of a pristine working directory for master created with git clone before you make any local changes at all? If so, I guess that means Cygwin git is now interpreting your git platform as Unix with LF endings on text files, and your bad results yesterday were due to you creating that working directory in the past with an old Cygwin git version (or else some non-Cygwin git version) that interpreted your git platform to be CRLF. Does that seem like a reasonable hypothesis to explain yesterday's bad results and today's good results? 2. Assuming LF what happens on a throwaway topic branch if you use a normal Windows editor to make a file change? In particular you should check that the file created by that editor is CRLF, and if so, what what happens if you attempt to commit that file? From my own experience with attempting to commit CRLF files, my prediction is the commit will tell you it is changing the repository result to LF (as it should) and leaving the working directory file as CRLF (which is problematic in my view, but that is what happened to me). Anyhow, if your working directory starts out as LF, you are going to have to work pretty hard to keep it LF when using ordinary Windows tools to make changes. So you might want to get clarification on the Cygwin list about why Cygwin's git is creating LF working directories for a repository like ours where the .gitattributes files says text=auto, i.e., all working directories should have native line endings. 2. Could you double-check that when you unpacked the tarball from me the patchfile results were LF and not CRLF? (It might make a difference whether you unpack with Cygwin tar or some other tar.) 3. Assuming you confirm above that both your working directory and patch files are LF could you try the experiments of using "git am" (from a fresh start each time) with (1) "--keep-cr", (2) "--no-keep-cr", and (3) neither option? My extremely tentative prediction is the --keep-cr option will fail (because it will attempt to convert the patch file to CRLF before applying), and the other two will succeed but it would be good for you to let us know exactly what happens in the three different cases as a guide to what to expect on git CRLF platforms. One sure conclusion is that Windows users attempting to communicate with "git format-patch"/"git am" must look at their working directory (especially if they are using Cygwin git) to determine if it is CRLF or LF, and similarly for any patch files. I am pretty sure the --no-keep-cr and ---keep-cr "git am" options will help sort out when there is a mismatch in line-endings, but the experiments mentioned in 3 should help confirm/disprove that hypothesis. 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
