When working in a team, the Software got distributed and is in use or when the Software became big, then releasing SW is no more a simple process. Working with a version control system, tagging the SW, creating a release candidate, writing test cases, testing and qualifying takes place to finally have a version to be released.

But know if in a released SW a small bug gets found or a small improvement is made or a new feature be added, what to do? A single developer might do a fork of the development tree to have a well running version, but if others further develop the SW soon the overview is lost. Version control systems help to merge everything together but this is not a trivial task.

An other way is simply writing down what should be changed in the original released code and have this computer readable so it can also be applied automatically by a computer. This is basically what a patch is. The patch can be created automatically using programs as diff:

diff <file1><file2> will show the difference in plain text in the console, but information is missing to locate the lines. Therefore there is the unified format:

diff --unified <file1><file2> that prints per default the 3 lines of text common to both files before and after the difference occurs. Writing the line numbers where the difference occur could become very complicated when lines would be added and others removed.

Alternatively of --unified --context could be used to get an other format. Finally the patch need to go into a file diff --unified <file1><file2> > <name>.patch

Instead of single files also directories can be passed to diff however diff --recursive must be added that also subdirectories are compared.

To change the original file the patch can be applied patch <original file><name>.patch Now diff <file1><file2> , diff -s <file1><file2> or diff --report-identical-files <file1><file2> will confirm the success.

The above works just if <file1> has a different name than <file2> but normally they have the same name and are therefore in two different directories. In this case diff needs to have also the path to those two files. Now applying the patch gets a bit more complicated.

patch < <name>.patch will do the job when having path and original file in the same directory.

However this is also not always the case. Going into the directory where the file to patch is and adding the path to the patch works. patch < <path>/<name>.patch

Finally when not being in the directory of the file to be patched there is the -p<n> command line option that shortens the path of the file to be patched inside the patch file so the original file is found. This option is very often used in scripts that build the source.


Do not create the patch in the directory where the file to be patched is, since then no path appears in the patch file and an automated script running in the top directory will not find the file since it has no indication of the subdirectories names and structure. The the -p<n> command line option can just remove path names but not add.

The necessary number to the -p<n> command line option tells how much of the path needs to be shortened. patch -p0 < <name>.patch

Linurs Servernest startpage