public inbox for patchutils-list@sourceware.org
 help / color / mirror / Atom feed
* patch subtraction bug
@ 2006-10-23 22:26 Eli Carter
  2006-10-24 11:08 ` Tim Waugh
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Carter @ 2006-10-23 22:26 UTC (permalink / raw)
  To: patchutils-list

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: patch subtraction bug
  2006-10-23 22:26 patch subtraction bug Eli Carter
@ 2006-10-24 11:08 ` Tim Waugh
  2006-10-24 14:37   ` Eli Carter
  0 siblings, 1 reply; 3+ messages in thread
From: Tim Waugh @ 2006-10-24 11:08 UTC (permalink / raw)
  To: Eli Carter; +Cc: patchutils-list

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: patch subtraction bug
  2006-10-24 11:08 ` Tim Waugh
@ 2006-10-24 14:37   ` Eli Carter
  0 siblings, 0 replies; 3+ messages in thread
From: Eli Carter @ 2006-10-24 14:37 UTC (permalink / raw)
  To: Tim Waugh; +Cc: Eli Carter, patchutils-list

> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-10-24 14:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-23 22:26 patch subtraction bug Eli Carter
2006-10-24 11:08 ` Tim Waugh
2006-10-24 14:37   ` Eli Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).