3.10. Apply a patch from someone else

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]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.

3.10.1. Using patch

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 -pat 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 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 Makefile.am.