Sometimes you need to apply a patch to your private source tree. Maybe because you want to try a patch from someone on the developer mailing list, or you want to check your own patch before submitting.
![]() | Warning! |
---|---|
If you have problems applying a patch, make sure the line endings (CR/NL) of the patch and your source files match. |
Given the file new.diff
containing a unified diff,
the right way to call the patch tool depends on what the pathnames in
new.diff
look like.
If they're relative to the top-level source directory - for example, if a
patch to prefs.c
just has prefs.c
as the file name - you'd run it as:
patch -p0 <new.diff
If they're relative to a higher-level directory, you'd replace 0 with the
number of higher-level directories in the path, e.g. if the names are
wireshark.orig/prefs.c
and
wireshark.mine/prefs.c
, you'd run it with:
patch -p1 <new.diff
If they're relative to a subdirectory
of the top-level
directory, you'd run patch in that
directory and run it with -p0
.
If you run it without -p
at all, the patch tool
flattens path names, so that if you
have a patch file with patches to Makefile.am
and
wiretap/Makefile.am
,
it'll try to apply the first patch to the top-level
Makefile.am
and then apply the
wiretap/Makefile.am
patch to the top-level
Makefile.am
as well.
At which position in the filesystem should the patch tool be called?
If the pathnames are relative to the top-level source directory, or to a directory above that directory, you'd run it in the top-level source directory.
If they're relative to a subdirectory
- for example,
if somebody did a patch to "packet-ip.c" and ran "diff" or "svn diff" in
the "epan/dissectors" directory - you'd run it in that subdirectory.
It is preferred that people NOT
submit patches like
that - especially if they're only patching files that exist in multiple
directories, such as Makefile.am
.