>>> After learning to my horror that gnu patch will,
>>> if a patch was made to be applied with option -p0,
>>> sometimes apply patches to your 'clean' tree
>>> (the one with the ---'s) instead of the target
>>> tree (the one with the +++'s) I decided to switch
>>> to -p1, and that is how this patch is to be applied.
>> The worst thing is that gnu patch will make
>> this decision on a per-file basis, so you
>> can't then back out the changes with -R.
>> Do like this:
>> diff -Naurd old new
>> IMPORTANT: the directory names should have
>> the same number of characters in them.
> Why is that?
File selection uses a really crazy algorithm.
If you set POSIXLY_CORRECT in your environment,
it gets a bit better, but you don't get the
rejection files then. As a patch creator, you
should not assume that POSIXLY_CORRECT is
set or not.
----------- the insanity -------------
Ignoring RCS/ClearCase/SCCS, the algorithm is
claimed to be:
patch takes an ordered list of candidate file names
old, new, index [index is from "Index:" line]
If some of the named files exist, patch selects
the first name if conforming to POSIX, and the
"best" [*] name otherwise.
If no named files exist ... some names are given,
patch is not conforming to POSIX, and the patch
appears to create a file, patch selects the "best" [*]
name requiring the creation of the fewest directories.
else ask the user
The "best" name:
patch first takes all the names with the fewest path
name components; of those, it then takes all the
names with the shortest basename; of those, it then
takes all the shortest names; finally, it takes the
first remaining name.
Given this complexity, do you trust the man page?
Follow my advice if you want to play it safe.
>> Do not try something like:
>> diff -Naurd bad idea
>> diff -Naurd doomed 2fail
>> Don't use "linux" for a name. Don't use
>> anything Linus might use. Pick your own
>> equal-length directory names, and don't
>> distribute tarballs containing them.
>> This prevents source-destroying disasters.
> I think you're saying that patch is broken by design.
> And what's the standard argument for not fixing it?
Half of the badness is POSIX mandated. As for
the other half... well, you should produce
patches that work with the existing tools.
Since good patches work with the existing
tools, there is no need to fix anything. :-/
Note who wrote patch. Note who wrote perl.
Any questions? (such behavior is nice for
a UI, for example a web browser URL parser,
but not for automated tools)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/