On 2015-12-22 09:04-0000 Arjen Markus wrote:
> 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.
Hi Arjen:
>From these results my guess is it was the clean start itself (e.g.,
the actual file contents in bindings/f95 rather than line endings
there) that was essential. For example, my initial commit included all
your Fortran changes so git am for that first patch file would fail it
you attempted to apply it on top of your Fortran changes.
>
>> 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.
OK. Good to know.
>
>>
>> 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.
OK. Good to know.
>
>> 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.
Thanks for reporting all these results.
There was web comment that could be interpreted (probably wishful
thinking on my part when I thought you had a CRLF platform) as ---keep-cr
transforms LF to CRLF. Your experiments have confirmed that is not the
case, and it acts like it is documented which is that git-am
merely passes that flag to git mailsplit which in turn documents it as
--keep-cr
Do not remove \r from lines ending with \r\n
So it appears by default that git am and git mailsplit transform from
CRLF to LF. So to preserve CRLF you must use the --keep-cr option but it does
not
assert it, i.e., if the input patch files are LF it does not transform
them to CRLF (as you have confirmed).
So I think on LF Cygwin you should never use this option since either
it is a no-op if communicating with another LF platform or else it
would mess you up if communicating with a CRLF platform. However,
from web comment it still appears to be a must for CRLF platforms
communicating with other CRLF platforms. And for cases where CRLF
platforms are trying to apply LF patches, I suspect the only recourse
is to transform the patches to CRLF before applying them with the
--keep-cr option of git am.
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
