Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
Comments
Comment #1
robin monks commentedYup, 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
Comment #2
drummOffset 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.
Comment #3
robin monks commentedIf 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
Comment #4
dmitrig01 commentedI 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?
Comment #5
dmitrig01 commentedAnd 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...)
Comment #6
robin monks commentedWell, 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
Comment #7
boombatower commentedI would vote for skipping this as patches should be made from root for standard, easy to read, and easy to test.