Patch without changing owner and group

If you're not giving any option to patch other than -pN, it only creates those files when a patch fails to apply cleanly.

So, one option is to stop creating (or accepting) bad patches. :)

Back in the real world, this is a feature. When patch(1) fails to apply a patch segment to the original file, it saves the temporary original file copy out durably as *.orig, dumps the rejected segment to *.rej, and continues trying to apply patch segments. The idea is that you can open the *.rej file and complete the patch process manually by copying bits and pieces over to the patched file. The *.orig file can also be useful when the patch process accidentally wrecks something, and you need to refer to the original version to fix it.

I don't always fix a bad patch with text from the *.rej and *.orig files, but it's nice to have them in case I need them.

Once I've fixed up a bad patch, I run the following script at the project root to quickly clean things up:

#!/bin/bash
find . '(' \
    -name \*-baseline -o \
    -name \*-merge -o \
    -name \*-original -o \
    -name \*.orig -o \
    -name \*.rej \
')' -delete

I call it cleanup-after-bad-patch because the long name partially insures against running this accidentally, since it could remove files you still need. To be honest, though, I normally run it by typing cleanTabEnter, that being sufficient to find this script in the PATH on my development machines.

The additional patterns it checks for are for the files output by my version control system of choice when it encounters the same problem during a merge operation. You may wish to adjust it for your VCS/SCM tools.

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.