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.
|Beware line endings|
If you have problems applying a patch, make sure the line endings (CR/LF) 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
If you run it without
-pat all, the patch tool
flattens path names, so that if you
have a patch file with patches to CMakeLists.txt and
it’ll try to apply the first patch to the top-level
CMakeLists.txt and then apply the
wiretap/CMakeLists.txt patch to the top-level
CMakeLists.txt 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
git 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 CMakeLists.txt.