From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11728 invoked by alias); 24 Oct 2006 11:08:34 -0000 Received: (qmail 11700 invoked by uid 22791); 24 Oct 2006 11:08:34 -0000 X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Oct 2006 11:08:26 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9OB8MBU006353; Tue, 24 Oct 2006 07:08:22 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9OB8MuI004392; Tue, 24 Oct 2006 07:08:22 -0400 Received: from [10.13.248.27] (vpn-248-27.boston.redhat.com [10.13.248.27]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k9OB8LkW030367; Tue, 24 Oct 2006 07:08:22 -0400 Subject: Re: patch subtraction bug From: Tim Waugh To: Eli Carter Cc: patchutils-list@sourceware.org In-Reply-To: <53689.10.6.7.70.1161642393.squirrel@mail.ie.commprove.com> References: <53689.10.6.7.70.1161642393.squirrel@mail.ie.commprove.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9q5NzsMpB++ub+ttkPxv" Date: Tue, 24 Oct 2006 11:08:00 -0000 Message-Id: <1161688100.4287.5.camel@cyberelk.elk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-7.fc6) X-Virus-Checked: Checked by ClamAV on sourceware.org X-IsSubscribed: yes Mailing-List: contact patchutils-list-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: patchutils-list-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00001.txt.bz2 --=-9q5NzsMpB++ub+ttkPxv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1226 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. >=20 > First, pull one change out of a larger patch: > filterdiff -p1 -i some/file.py --hunks=3D5 < 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 >=20 > 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. */ --=-9q5NzsMpB++ub+ttkPxv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFPfQkFLeBZ6VVmn8RAsSbAJ9ejOyd/v6OgZeFF877UCH4B2QUvQCdGHgF VA1Lar7EttU6sxmVRQ6+brY= =FD+o -----END PGP SIGNATURE----- --=-9q5NzsMpB++ub+ttkPxv--