Red Hat Bugzilla – Bug 13613
Patch barfs on some cvs diffs
Last modified: 2008-05-01 11:37:56 EDT
Most cvs diff headers look something like:
RCS file: /cvsroot/mozilla/caps/src/Makefile.in,v
retrieving revision 1.32
diff -u -r1.32 Makefile.in
--- Makefile.in 2000/05/14 10:38:48 1.32
+++ Makefile.in 2000/05/16 02:59:30
Since cvs does a relative diff against the file in question, the new & old
names only contain the basename of the file. In order for patch to see the
relative path set in Index:, you must set the POSIXLY_CORRECT env
variable. This is where things get weird.
From the patch manpage:
7 If there is an Index: line in the leading garbage and
if either the old and new names are both absent or the
POSIXLY_CORRECT environment variable is set, patch
takes the name in the Index: line.
7 For the purpose of the following rules, the names are
considered to be in the order (old, new, index),
regardless of the order that they appear in the header.
7 If some of the named files exist, patch uses the first
name if the POSIXLY_CORRECT environment variable is
set, and the best name otherwise.
The problem is that if you already have a file with the same base name in
the toplevel directory, patch will use that file instead. In the above
example, I had to remove the toplevel Makefile.in before that patch would
work. I think that if POSIXLY_CORRECT is set, patch should use the name
from Index: regardless of the settings of old, new & a file with the same
name in the current directory.
Created attachment 961 [details]
Use Index: to determine name if POSIXLY_CORRECT & Index: are used.
Is this still a problem with patch 2.5.4?
Yes, patch 2.5.4 exhibits the same behavior.
Oh, and as a sidenote, it only appears to occur with multi-file patches. If I
attempt to patch just caps/src/Makefile.in, patch works fine as is.
Can you attach a testcase?
Do you have a testcase?
Created attachment 3659 [details]
I've found a test case.
Patch is acting according to POSIX. The bug is in the POSIX spec. :-((
The Single Unix Spec seems to be better here, but it hardly seems fair to follow
that behaviour while POSIXLY_CORRECT is set.
Fixing this requires new options to patch I think.
I'm wrong. Single UNIX is just as bad, and will check for non-Index: names
Incidentally, cvs-1.10.8-8 generates patches (from 'cvs diff') that don't have