plplot-devel

[Plplot-devel] Problems applying patches

[Arjen M. <Arj...@de...>]

Hi everyone,



Alan and I are developing a new Fortran binding and we would like to cooperate using patches rather than sending complete source files to one another. However, I am experiencing weird problems with the "git am" command. It simply doesn't apply the patches. This may have to do with the line endings (I work on Windows with CRLF and Alan on Linux with CR), but I have been unable to figure out how to get git to do its work.



1.      Applying the patch to the source files as they are (CRLF) gave errors that the patch didn't apply

2.      Changing the line endings to CR gave the message that the file didn't match the index

3.      Committing and then applying the patch got me back to the first situation



I simply have no clue as to what I am supposed to do here. My current idea is to use "patch" instead of "git am" to incorporate the changes, but that may require some tweaking on my part of the dozen patch files Alan provided.



Does anyone have a better idea?



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.

Re: [Plplot-devel] Problems applying patches

[Alan W. I. <ir...@be...>]

On 2015-12-20 12:34-0000 Arjen Markus wrote:

> Hi everyone,

> Alan and I are developing a new Fortran binding and we would like to
cooperate using patches rather than sending complete source files to
one another. However, I am experiencing weird problems with the "git
am" command. It simply doesn't apply the patches. This may have to do
with the line endings (I work on Windows with CRLF and Alan on Linux
with CR), but I have been unable to figure out how to get git to do
its work.

Hi Arjen:

I was about to answer your off-list post to me concerning this issue,
but taking this conversation to the list at this stage is a good idea
so I will answer you here instead.

Just to clarify all Unix platforms like mine use LF (not CR) for text
file line endings.

So when I create the series of patches with git --format-patch, the
context lines and change lines are all LF.  And there doesn't appear
to be any obvious option to git format-patch to change those to CRLF.
But Arjen's checked out working directory text files are all
(correctly for his platform) CRLF so the patch won't apply without a
transformation of those LF endings in the patch context and changed
lines to CRLF.

By the way, "fresh start" below means starting with a new topic branch
that is generated from a clean up-to-date master branch.  git am
--abort probably produces that, but I wouldn't count on that until we
gain more experience.

What happens with a fresh start if you try "git am --keep-cr"?  I
mentioned this possibility off-list before, but as far as I can tell
you have not tried it yet.

That seems to be the universal advice about what option should be used
on Windows platforms with "git am" _even when communicating between
Windows platforms_. In the current context of communicating from my
Unix platform to your Windows platform I am hoping that what --keep-cr
actually does is automatically transform the LF patch context lines
and changed lines in my series of patches to CRLF before applying.

If that doesn't work, another possibility to try (starting with a
fresh start) is to run my patch series through a utility to convert
all line endings in the patch file to CRLF before you attempt to use
"git am --keep-cr".  I cannot see how that method could possibly
fail.... (Famous last words.  :-) )

But if neither of those ideas work, I will try a question to the git
list since surely there must be a method of working with "git
format-patch"/"git am" that allows collaboration between developers on
Windows and Unix platforms with all line endings issues automatically
taken care of.

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
__________________________

Re: [Plplot-devel] Problems applying patches

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> I was about to answer your off-list post to me concerning this issue, but taking this
> conversation to the list at this stage is a good idea so I will answer you here instead.
>
...
>
> What happens with a fresh start if you try "git am --keep-cr"?  I mentioned this
> possibility off-list before, but as far as I can tell you have not tried it yet.
>
> That seems to be the universal advice about what option should be used on
> Windows platforms with "git am" _even when communicating between Windows
> platforms_. In the current context of communicating from my Unix platform to your
> Windows platform I am hoping that what --keep-cr actually does is automatically
> transform the LF patch context lines and changed lines in my series of patches to
> CRLF before applying.
>

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.

> If that doesn't work, another possibility to try (starting with a fresh start) is to run my
> patch series through a utility to convert all line endings in the patch file to CRLF
> before you attempt to use "git am --keep-cr".  I cannot see how that method could
> possibly fail.... (Famous last words.  :-) )
>
> But if neither of those ideas work, I will try a question to the git list since surely there
> must be a method of working with "git format-patch"/"git am" that allows collaboration
> between developers on Windows and Unix platforms with all line endings issues
> automatically taken care of.
>
A complication might be that I am using git via Cygwin and Cygwin expects shell scripts to be in UNIX format (LF line endings). IIRC, Cygwin allows either format. You have to chose at installation time.

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.

Re: [Plplot-devel] Problems applying patches

[Arjen M. <Arj...@de...>]

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.

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.

Re: [Plplot-devel] Problems applying patches

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] Problems applying patches

[Alan W. I. <ir...@be...>]

On 2015-12-21 11:37-0800 Alan W. Irwin wrote:

> 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.

In addition to the other experiments I asked you to perform, you
should also let us know the complete results of

git config --list

In particular I am wondering if

core.eol

is set.

That variable gives you complete control over the line endings used in
your working directory.  However, if using git config to set that
variable be sure you use the --global setting so that you do not
change the repository version of the config file for the rest of us
(see also
<https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).

Note, if core.eol is not set the default is "native" which I think
might be what you want.

However, here is the Key question: are you currently getting a LF
working directory because Cygwin sets core.eol to lf by default or
does Cygwin git assume that "native" really means a LF working
directory on Cygwin platforms?

Since your editing tools are likely happier with a CRLF working
directory, I think that is what you ultimately want.  Of course, that
likely means you will have to run any patch from me through a LF to
CRLF converter and use the "--keep-cr" option for "git am" (which
further reading tells me simply avoids doing the default change from
CRLF to LF, but also does not enforce CRLF if the patch file is LF).

Anyhow, I would take the time now to set up git line endings exactly
the way you want them based on your experiments editing files and
using git am.  That would be much better than enforcing LF now (say
with core.eol) just to keep git-am happy and regretting that
working-directory setting later once you start actually making further
changes with your favorite editor.

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
__________________________

Re: [Plplot-devel] Problems applying patches

[Chris M. <dev...@gm...>]

I use cygwin git and it seems to behave like a
standard unix git as far as line ending.  I also use
the cygwin vim which has no problem leaving
the LF untouched.  Your mileage with windows
editors will definitely vary!

--Chris

On 12/21/2015 15:46, Alan W. Irwin wrote:
> On 2015-12-21 11:37-0800 Alan W. Irwin wrote:
>
>> 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.
> In addition to the other experiments I asked you to perform, you
> should also let us know the complete results of
>
> git config --list
>
> In particular I am wondering if
>
> core.eol
>
> is set.
>
> That variable gives you complete control over the line endings used in
> your working directory.  However, if using git config to set that
> variable be sure you use the --global setting so that you do not
> change the repository version of the config file for the rest of us
> (see also
> <https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).
>
> Note, if core.eol is not set the default is "native" which I think
> might be what you want.
>
> However, here is the Key question: are you currently getting a LF
> working directory because Cygwin sets core.eol to lf by default or
> does Cygwin git assume that "native" really means a LF working
> directory on Cygwin platforms?
>
> Since your editing tools are likely happier with a CRLF working
> directory, I think that is what you ultimately want.  Of course, that
> likely means you will have to run any patch from me through a LF to
> CRLF converter and use the "--keep-cr" option for "git am" (which
> further reading tells me simply avoids doing the default change from
> CRLF to LF, but also does not enforce CRLF if the patch file is LF).
>
> Anyhow, I would take the time now to set up git line endings exactly
> the way you want them based on your experiments editing files and
> using git am.  That would be much better than enforcing LF now (say
> with core.eol) just to keep git-am happy and regretting that
> working-directory setting later once you start actually making further
> changes with your favorite editor.
>
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problems applying patches

[Arjen M. <Arj...@de...>]

Hi Chris, Alan,



My favourite editor and the one I use less frequently but nevertheless use from time to time both can smoothly handle LF line endings and store files either as LF or CRLF. In fact, Cygwin git behaving the way it does, makes sure that the shell scripts for testing work fine - my Cygwin installation expects such files to follow the UNIX convention.



The result of "git config -list" is surprisingly short:


git config --list
user.name=Arjen Markus
user.email=arj...@de...


So core.eol is not set. My guess is that the default "native" is now the default for the Cygwin installation, which definitely uses the UNIX convention.

More on the other experiments later.

Regards,

Arjen


> -----Original Message-----
> From: Chris Marshall [mailto:dev...@gm...]
> Sent: Monday, December 21, 2015 10:07 PM
> To: plp...@li...
> Subject: Re: [Plplot-devel] Problems applying patches
>
> I use cygwin git and it seems to behave like a standard unix git as far as line ending.
> I also use the cygwin vim which has no problem leaving the LF untouched.  Your
> mileage with windows editors will definitely vary!
>
> --Chris
>
> On 12/21/2015 15:46, Alan W. Irwin wrote:
> > On 2015-12-21 11:37-0800 Alan W. Irwin wrote:
> >
> >> 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.
> > In addition to the other experiments I asked you to perform, you
> > should also let us know the complete results of
> >
> > git config --list
> >
> > In particular I am wondering if
> >
> > core.eol
> >
> > is set.
> >
> > That variable gives you complete control over the line endings used in
> > your working directory.  However, if using git config to set that
> > variable be sure you use the --global setting so that you do not
> > change the repository version of the config file for the rest of us
> > (see also
> > <https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).
> >
> > Note, if core.eol is not set the default is "native" which I think
> > might be what you want.
> >
> > However, here is the Key question: are you currently getting a LF
> > working directory because Cygwin sets core.eol to lf by default or
> > does Cygwin git assume that "native" really means a LF working
> > directory on Cygwin platforms?
> >
> > Since your editing tools are likely happier with a CRLF working
> > directory, I think that is what you ultimately want.  Of course, that
> > likely means you will have to run any patch from me through a LF to
> > CRLF converter and use the "--keep-cr" option for "git am" (which
> > further reading tells me simply avoids doing the default change from
> > CRLF to LF, but also does not enforce CRLF if the patch file is LF).
> >
> > Anyhow, I would take the time now to set up git line endings exactly
> > the way you want them based on your experiments editing files and
> > using git am.  That would be much better than enforcing LF now (say
> > with core.eol) just to keep git-am happy and regretting that
> > working-directory setting later once you start actually making further
> > changes with your favorite editor.
> >
> > 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
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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.

Re: [Plplot-devel] Problems applying patches

[Arjen M. <Arj...@de...>]

Hi Alan,



See below.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 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.

Re: [Plplot-devel] Problems applying patches

[Alan W. I. <ir...@be...>]

On 2015-12-22 09:04-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> See below.
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> 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
__________________________