Hi Alan,
See below. > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > > 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? > No, I have checked several working directories I have for PLplot, accumulated over the years :), but I find LF line endings in various files that I did not touch myself. > 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. If I edit a file which is then saved with CRLF and commit it, I get a warning about the CR, but the file is left as it is. Luckily my text editors don't mind. > > 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.) > No, the individual patch files are simply LF, as I expected actually - the unpacking facility does not interpret files in any way. > 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. > Actually when I succeeded with applying the patch yesterday, I used the -keep-cr option. So that is working correctly in my setup. Just now I tried the other possibilities: --no-keep-cr and no options at all. They both work in exactly the same way as -keep-cr. A few messages about trailing whitespace and that is it. > 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. > Not sure what to conclude from the above experiments. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
