I tried abusing patchutils in a new way today, and it didn't do what I wanted. First, pull one change out of a larger patch: filterdiff -p1 -i some/file.py --hunks=5 < diff > one-change.patch Now, I want to remove that change from the larger patch, so I combine the larger patch with a reversed version of the the one-change.patch: interdiff one-change.patch /dev/null | combinediff diff /dev/stdin > rest.patch What I got was a patch with the hunk from one-change.patch in rest.patch twice with different line numbers for the change. When I tried the same abuse, but filtering only on file (no --hunks=), combinediff removed that file's deltas from the original diff, just as I hoped it would. So it looks to me like combinediff isn't accounting for the change in line numbers for a file due to one patch that affects the target line numbers in the other patch. If I have a chance, I'll look at the code and try to make this work, but it'll be another day. Have fun, Eli eli.carter@commprove.com
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --] On Mon, 2006-10-23 at 17:26 -0500, Eli Carter wrote: > I tried abusing patchutils in a new way today, and it didn't do what I > wanted. > > First, pull one change out of a larger patch: > filterdiff -p1 -i some/file.py --hunks=5 < diff > one-change.patch > Now, I want to remove that change from the larger patch, so I combine the > larger patch with a reversed version of the the one-change.patch: > interdiff one-change.patch /dev/null | combinediff diff /dev/stdin > > rest.patch > > What I got was a patch with the hunk from one-change.patch in rest.patch > twice with different line numbers for the change. Hmm, I just tried this myself and got the expected results -- the entire original patch with the single change removed. Sounds like it depends on the input you give it. One thing that *might* account for it is described in the 'BUGS' section of the interdiff man page: There are some sets of patches in which there is just not enough information to produce a proper interdiff. In this case, the strategy employed is to revert the original patch and apply the new patch. This, unfortunately, means that interdiffs are not guaranteed to be reversible. Do you think it could be that? Tim. */ [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --]
> On Mon, 2006-10-23 at 17:26 -0500, Eli Carter wrote:
>> I tried abusing patchutils in a new way today, and it didn't do what I
>> wanted.
>>
>> First, pull one change out of a larger patch:
>> filterdiff -p1 -i some/file.py --hunks=5 < diff > one-change.patch
>> Now, I want to remove that change from the larger patch, so I combine
>> the
>> larger patch with a reversed version of the the one-change.patch:
>> interdiff one-change.patch /dev/null | combinediff diff /dev/stdin >
>> rest.patch
>>
>> What I got was a patch with the hunk from one-change.patch in rest.patch
>> twice with different line numbers for the change.
>
> Hmm, I just tried this myself and got the expected results -- the entire
> original patch with the single change removed.
>
> Sounds like it depends on the input you give it. One thing that *might*
> account for it is described in the 'BUGS' section of the interdiff man
> page:
>
> There are some sets of patches in which there is just not enough
> information to produce a proper interdiff. In this case, the strategy
> employed is to revert the original patch and apply the new patch.
> This, unfortunately, means that interdiffs are not guaranteed to be
> reversible.
>
> Do you think it could be that?
Perhaps... but I don't think--wait...
The doubling of the patch at the end I thought was [apply change] [apply
change], but the second one was the reverse of the first, as you
described... I misread the patch.
Oops.
Hmm... I still think interdiff has enough information to cancel the
hunks... but I'll have to play with the sources before I really make that
claim.
Sorry for wasting your time,
Eli