|Comparing and Merging Files with GNU diff and patch|
by David MacKenzie, Paul Eggert, and Richard Stallman
Paperback (6"x9"), 120 pages
RRP £12.95 ($19.95)
"Well packaged... the quality of information is excellent" --- Linux User and Developer Magazine (Issue 36, Feb 2004) Get a printed copy>>>
patch Find Inexact Matches
For context diffs, and to a lesser extent normal diffs,
detect when the line numbers mentioned in the patch are incorrect, and
it attempts to find the correct place to apply each hunk of the patch.
As a first guess, it takes the line number mentioned in the hunk, plus
or minus any offset used in applying the previous hunk. If that is not
the correct place,
patch scans both forward and backward for a
set of lines matching the context given in the hunk.
patch looks for a place where all lines of the context
match. If it cannot find such a place, and it is reading a context or
unified diff, and the maximum fuzz factor is set to 1 or more, then
patch makes another scan, ignoring the first and last line of
context. If that fails, and the maximum fuzz factor is set to 2 or
more, it makes another scan, ignoring the first two and last two lines
of context are ignored. It continues similarly if the maximum fuzz
factor is larger.
-F lines or
--fuzz=lines option sets the
maximum fuzz factor to lines. This option only applies to context
and unified diffs; it ignores up to lines lines while looking for
the place to install a hunk. Note that a larger fuzz factor increases
the odds of making a faulty patch. The default fuzz factor is 2; there
is no point to setting it to more than the number of lines of context
in the diff, ordinarily 3.
patch cannot find a place to install a hunk of the patch, it
writes the hunk out to a reject file (see section 10.10 Reject File Names, for information
on how reject files are named). It writes out rejected hunks in context
format no matter what form the input patch is in. If the input is a
ed diff, many of the contexts are simply null. The
line numbers on the hunks in the reject file may be different from those
in the patch file: they show the approximate location where
thinks the failed hunks belong in the new file rather than in the old
--verbose option is given, then
as it completes each hunk
patch tells you whether the hunk
succeeded or failed, and if it failed, on which line (in the new file)
patch thinks the hunk should go. If this is different from the
line number specified in the diff, it tells you the offset. A single
large offset may indicate that
patch installed a hunk in
the wrong place.
patch also tells you if it used a fuzz factor
to make the match, in which case you should also be slightly suspicious.
patch cannot tell if the line numbers are off in an
script, and can only detect wrong line numbers in a normal diff when it
finds a change or delete command. It may have the same problem with a
context diff using a fuzz factor equal to or greater than the number of
lines of context shown in the diff (typically 3). In these cases, you
should probably look at a context diff between your original and patched
input files to see if the changes make sense. Compiling without errors
is a pretty good indication that the patch worked, but not a guarantee.
A patch against an empty file applies to a nonexistent file, and vice versa. See section 10.4 Creating and Removing Files.
patch usually produces the correct results, even when it must
make many guesses. However, the results are guaranteed only when
the patch is applied to an exact copy of the file that the patch was
|ISBN 0954161750||Comparing and Merging Files with GNU diff and patch||See the print edition|