Red Hat Bugzilla – Bug 68555
editdiff (really rediff) fails
Last modified: 2008-05-01 11:38:02 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020628 Description of problem: I'll append a test file which contains a patch. If editdiff is used and the first chunk is removed rediff will abort and leave no usable find behind. Total loss of data. This applies as far as I can see to al versions up to and including the current raw hide which is why I've filed the bug for rawhide. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.editdiff AAAA 2.remove first chunk 3.leave editor Actual Results: rediff: src/rediff.c:468: show_modified_hunk: Assertion `!read_atatline (line, &orig_offset, &orig_count, &new_offset, &new_count)' failed. /usr/bin/editdiff: line 68: 11476 Aborted rediff "${TMPD}/${NAME}.orig" "${TMPD}/${NAME}" >"${FILE}" Expected Results: new patch with first chunk removed Additional info:
Created attachment 64744 [details] Test input
editdiff backs the original file up with extension '.orig', so it shouldn't cause data loss. Thanks for the test case.
Rediff only handles unified diff format currently, I'm afraid. I'll stick in a check there to make it do something sensible when confronted with context diff.
The check is now in CVS.
As a work-around, you can use filterdiff to select hunks from a diff. At least filterdiff understands context format.
This check is now in patchutils-0.2.17-1.