# Patchdiff 6 messages from 2010-01-27 to 2010-01-27. Participants: Sverre Rabbelier, Jonathan Nieder, Nicolas Pitre, Junio C Hamano, Bert Wesarg. Thread: https://gitlist.dev/t/22403 ## Sverre Rabbelier, 2010-01-27 00:06 Subject: Patchdiff Message-ID: URL: https://gitlist.dev/e/fabb9a1e1001261606i4f706387vaf5647436e454fb4%40mail.gmail.com ``` Heya, Do we have anything that allows me to compare two versions of a patch? In theory it'd do something like "apply both patches to the their merge base, then show the diff between the results". I don't think we have something like that, since there's probably some major caveats about conflicts when applying the patches to their merge-base. Or perhaps my theory is silly, and there's an easier way to compare two patches (other than looking at a diff's diff, which I've never been good at). -- Cheers, Sverre Rabbelier ``` ## Jonathan Nieder, 2010-01-27 01:09 Subject: Re: Patchdiff Message-ID: <20100127010954.GA7628@progeny.tock> URL: https://gitlist.dev/e/20100127010954.GA7628%40progeny.tock In-Reply-To: ``` Hi, Sverre Rabbelier wrote: > Do we have anything that allows me to compare two versions of a patch? > In theory it'd do something like "apply both patches to the their > merge base, then show the diff between the results". It’s not git specific, but maybe interdiff [1] could help. Ciao, Jonathan [1] http://cyberelk.net/tim/data/patchutils/stable/ ``` ## Nicolas Pitre, 2010-01-27 01:19 Subject: Re: Patchdiff Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.1001262014250.1681%40xanadu.home In-Reply-To: ``` On Wed, 27 Jan 2010, Sverre Rabbelier wrote: > Heya, > > Do we have anything that allows me to compare two versions of a patch? > In theory it'd do something like "apply both patches to the their > merge base, then show the diff between the results". I don't think we > have something like that, since there's probably some major caveats > about conflicts when applying the patches to their merge-base. Or > perhaps my theory is silly, and there's an easier way to compare two > patches (other than looking at a diff's diff, which I've never been > good at). What about Git's diff -c/--cc ? You'd have to reverse the parenthood logic though. Nicolas ``` ## Junio C Hamano, 2010-01-27 01:30 Subject: Re: Patchdiff Message-ID: <7vzl40wcz2.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vzl40wcz2.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre writes: >> Do we have anything that allows me to compare two versions of a patch? >> In theory it'd do something like "apply both patches to the their >> merge base, then show the diff between the results". I don't think we >> have something like that, since there's probably some major caveats >> about conflicts when applying the patches to their merge-base. Or >> perhaps my theory is silly, and there's an easier way to compare two >> patches (other than looking at a diff's diff, which I've never been >> good at). > > What about Git's diff -c/--cc ? You'd have to reverse the parenthood > logic though. When I did "diff --cc" originally, I thought about its interaction with reverse (-R), and gave up. The thing is, "--cc" output needs to show "here is _the_ end result", together with "and each sides did things in these different ways (shown with +/- annotations)". When showing a merge, there is one end result (the merged version), so it fits the model that is a natural extension of two-way diff. In the "two patches walked in a bar, modified the same version and produced two different results" case, the common thing is the preimage, not postimage. I couldn't come up with a combined output format that visually makes sense for that mode of operation. ``` ## Nicolas Pitre, 2010-01-27 01:40 Subject: Re: Patchdiff Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.1001262038130.1681%40xanadu.home In-Reply-To: <7vzl40wcz2.fsf@alter.siamese.dyndns.org> ``` On Tue, 26 Jan 2010, Junio C Hamano wrote: > When showing a merge, there is one end result (the merged version), so it > fits the model that is a natural extension of two-way diff. In the "two > patches walked in a bar, modified the same version and produced two > different results" case, the common thing is the preimage, not postimage. > I couldn't come up with a combined output format that visually makes sense > for that mode of operation. Hmmmmmm yeah. I didn't think it through all the way. Too bad. Nicolas ``` ## Bert Wesarg, 2010-01-27 07:06 Subject: Re: Patchdiff Message-ID: <36ca99e91001262306l58234073v83ce709bee6c54a0@mail.gmail.com> URL: https://gitlist.dev/e/36ca99e91001262306l58234073v83ce709bee6c54a0%40mail.gmail.com In-Reply-To: <7vzl40wcz2.fsf@alter.siamese.dyndns.org> ``` On Wed, Jan 27, 2010 at 02:30, Junio C Hamano wrote: > Nicolas Pitre writes: > >>> Do we have anything that allows me to compare two versions of a patch? >>> In theory it'd do something like "apply both patches to the their >>> merge base, then show the diff between the results". I don't think we >>> have something like that, since there's probably some major caveats >>> about conflicts when applying the patches to their merge-base. Or >>> perhaps my theory is silly, and there's an easier way to compare two >>> patches (other than looking at a diff's diff, which I've never been >>> good at). >> >> What about Git's diff -c/--cc ?  You'd have to reverse the parenthood >> logic though. > > When I did "diff --cc" originally, I thought about its interaction with > reverse (-R), and gave up. Actually, I have done this. My intention is to use this as a new merge conflict style. I will send the patch, but not today. Regards, Bert ```