bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patch troubles with CRLF's again


From: Mike Frysinger
Subject: Re: patch troubles with CRLF's again
Date: Sun, 15 Mar 2009 17:44:36 -0400
User-agent: KMail/1.11.1 (Linux/2.6.28; KDE/4.2.1; x86_64; ; )

On Sunday 15 March 2009 15:22:55 Andreas Gruenbacher wrote:
> On Thursday, 1 September 2005 8:06:27 Mike Frysinger wrote:
> > we're using patch-2.5.9 in Gentoo along with this CRLF patch:
> > http://lists.gnu.org/archive/html/bug-gnu-utils/2005-05/msg00012.html
> > we started using this patch after some patches were being rejected by
> > 2.5.9 but were working with 2.5.4
>
> Patch strips the trailing CRs as intended. Since the files being patch also
> have CRLF line endings, this causes the patch to fail. It is impossible to
> always get this right, we can only make patch do the right thing for what
> it is mainly intended to do. (Paul already discussed this in [1].)

while true, the new behavior prevents patches from Windows to ever be applied 
under a *nix system.  the latest versions says "if the patch header has CRLF, 
then it's been corrupted and so we should strip CRs from all lines".  this 
works if that is actually correct: the file being patched has LFs, a patch was 
generated on a *nix machine and had LFs, but then it was run through 
`unix2dos` changing the newline indicator to CRLFs.

if the patch was generated on a Windows machine, then it would make sense for 
the patch to have CRLFs on all lines as well as the files themselves.  that is 
the general code flow with the MAME project: a lot of people develop it under 
Windows and generate patches there.  attempts to apply said patches now 
results in failure.  we'd have to run a manual filter on the patch and convert 
just the patch headers to LF so that patch wouldnt strip the CRLFs from the 
patch content on us.  --binary wouldnt help us at all.

a better heuristic would be to actually test the line being patched.  does it 
end with CRLF ?  if so, leave the CRLFs in the hunk alone.  if it doesnt, 
automatically rip out the CR.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]