patch subtraction bug

patch subtraction bug

[Eli Carter]

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

Re: patch subtraction bug

[Tim Waugh]

[-- 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 --]

Re: patch subtraction bug

[Eli Carter]

> 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