Is there any standard option to create 'patch' P that works on file F in such way that it will keep working correctly when file F changes into F'.

So I will either have some mechanism that will change P into P' so that P'(F') produces the same change as P(F), or, preferably, I will have resilient P so that it can be used for both F & F'.

Currently I am using the regular expression search and replace to create such patch, but I wonder is there any standard way to do such thing.


This problem is known as merging. You have an original file A and two modified versions B and C, and you want to make a version D that combines both modifications. This only works if the changes are independent; otherwise, merging is a manual process. Handling merges of concurrent changes to source code is a frequent task in software engineering.

In simple cases, a patch produced by diff will already work if the source file has changed. The patch utility allows some “fuzz”: if you make a diff from A to B, and the areas affected by that diff are identical (but possibly at different offsets in the file) in A and C, then the patch will apply cleanly on C. This works well as long as the changed areas in B and C aren't at the same locations (there has to be a couple of lines' separation).

When patches don't apply cleanly, merging is a difficult and domain-specific problem. For example, consider these two changes:

A         B         C
a=2       a=3       b=2
x=a       x=a       x=b

Human beings tend to spot the pattern that B has changed 2 to 3 and C has renamed a to b, so the result of the merge should be b=3, x=b. But automated tools are likely to flag the first line as a conflict, because it's been modified in two different ways.

Writing a patch that “does something sensible” to both B and C is a difficult (AI-complete) problem. In practical cases, for many typical situations, using diff -u A B as the patch tends to either work and produce the desired D out of C, or fail with an error stating that the patch doesn't apply cleanly.


I wouldn't really recommend using sed for such a thing. The trouble is, that even if a patch applies it can often be with a "fuzz" - which means, that some of the context lines are not matched perfectly. While this often means that the underlying surrounding code changed slightly, it can also mean, that the patch applied in a wrong place (I've seen this happen, it wasn't nice and not easy to debug).

Additionally, even if the patch applies cleanly, chances are that it makes no sense semantically any more. To catch this however, you must be aware of the changes that took place in the patched code.

For the reasons stated, it is considered a good practice to review at least anything that applies with a fuzz (and probably also superficially check whatever applies with an offset). Having more than the default 3 lines of context might be a good idea too.

Having gone through the big fat warning, one of the ways to do this relatively painlessly is using a version control system, probably an advanced distribudet one like e.g. mercurial or git. Opinions on the choice between these two vary, Mercurial is a bit more similar to the older CVS and SVN than Git is, and arguably also has a better learning curve (whikle Git is claimed to be more feature rich).

In Mercurial has the Mercurial Queues (MQ) extension exactly for these cases. This Steve Losh's blog post is a rather nice introduction to using MQ and another good reading is this guide to MQ on Mozilla's developer website.

At times, patchutils can come in handy too.

  • Thanks for elaborate answer and the links. I will check them out. I understand the risks, however, this is not about the tool, but about its usage, and any tool is valuable in some context. – majkinetor Jan 7 '13 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.