Use correct -p option
drumm - October 11, 2007 - 19:01
| Project: | Test driven development infrastructure |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | dmitrig01 |
| Status: | won't fix |
Jump to:
Description
I would not turn away a patch made from an irregular root directory, and neither should the robot. Example at http://testing.drupal.org/node/130, which has other issues, but thats not the point.
#1
Yup, this is already a known issue. We need to cycle though:
1) normal patch <
2) patch -p0
3) -p1
...
We should go up to 20 for those doing dev in their Windows XP desktop subfolders ;)
We should also reroll the patch in this case (if the tests PASS), and also if:
1) The patch has offset
2) The patch was applied with fuzz
3) The patch is not unified.
Robin
#2
Offset and fuzz are fine, the patch still applies. Why would it need to be re-rolled?
Re-rolling non-unified patches is fine since those are harder to read.
#3
If it has a lot of offset or fuzz, it may be getting close to HEAD changing too much for it to apply. If we keep the patch applying cleanly, it's likely to have a longer "best before" date for committal to CVS.
Robin
#4
I think I might try to tackle this one (including the re-rolling part)
I had two questions though - a) how do I tell if it's not a unidiff? b) how do I tell if there's offset/fuzz?
#5
And another thing - how about patches that add/remove files? applying them works normally but re-rolling can be somewhat hard (have to edit CVS/Entries...)
#6
Well, offset/fuzz is reported in the stdout of patch. You'd need to capture it and grep for fuzz/offset.
Unified diffs use:
+++ add
--- remove
whereas standard diffs use:
> add
< remove
some fancy regex should do it.
(I'll let someone else answer the add/remove file question)
Robin
#7
I would vote for skipping this as patches should be made from root for standard, easy to read, and easy to test.