git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Patchdiff
@ 2010-01-27  0:06 Sverre Rabbelier
  2010-01-27  1:09 ` Patchdiff Jonathan Nieder
  2010-01-27  1:19 ` Patchdiff Nicolas Pitre
  0 siblings, 2 replies; 6+ messages in thread
From: Sverre Rabbelier @ 2010-01-27  0:06 UTC (permalink / raw)
  To: Git List

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

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

* Re: Patchdiff
  2010-01-27  0:06 Patchdiff Sverre Rabbelier
@ 2010-01-27  1:09 ` Jonathan Nieder
  2010-01-27  1:19 ` Patchdiff Nicolas Pitre
  1 sibling, 0 replies; 6+ messages in thread
From: Jonathan Nieder @ 2010-01-27  1:09 UTC (permalink / raw)
  To: Sverre Rabbelier; +Cc: Git List

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/

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

* Re: Patchdiff
  2010-01-27  0:06 Patchdiff Sverre Rabbelier
  2010-01-27  1:09 ` Patchdiff Jonathan Nieder
@ 2010-01-27  1:19 ` Nicolas Pitre
  2010-01-27  1:30   ` Patchdiff Junio C Hamano
  1 sibling, 1 reply; 6+ messages in thread
From: Nicolas Pitre @ 2010-01-27  1:19 UTC (permalink / raw)
  To: Sverre Rabbelier; +Cc: Git List

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

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

* Re: Patchdiff
  2010-01-27  1:19 ` Patchdiff Nicolas Pitre
@ 2010-01-27  1:30   ` Junio C Hamano
  2010-01-27  1:40     ` Patchdiff Nicolas Pitre
  2010-01-27  7:06     ` Patchdiff Bert Wesarg
  0 siblings, 2 replies; 6+ messages in thread
From: Junio C Hamano @ 2010-01-27  1:30 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Sverre Rabbelier, Git List

Nicolas Pitre <nico@fluxnic.net> 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.

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

* Re: Patchdiff
  2010-01-27  1:30   ` Patchdiff Junio C Hamano
@ 2010-01-27  1:40     ` Nicolas Pitre
  2010-01-27  7:06     ` Patchdiff Bert Wesarg
  1 sibling, 0 replies; 6+ messages in thread
From: Nicolas Pitre @ 2010-01-27  1:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List

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

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

* Re: Patchdiff
  2010-01-27  1:30   ` Patchdiff Junio C Hamano
  2010-01-27  1:40     ` Patchdiff Nicolas Pitre
@ 2010-01-27  7:06     ` Bert Wesarg
  1 sibling, 0 replies; 6+ messages in thread
From: Bert Wesarg @ 2010-01-27  7:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, Sverre Rabbelier, Git List

On Wed, Jan 27, 2010 at 02:30, Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@fluxnic.net> 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

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

end of thread, other threads:[~2010-01-27  7:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-27  0:06 Patchdiff Sverre Rabbelier
2010-01-27  1:09 ` Patchdiff Jonathan Nieder
2010-01-27  1:19 ` Patchdiff Nicolas Pitre
2010-01-27  1:30   ` Patchdiff Junio C Hamano
2010-01-27  1:40     ` Patchdiff Nicolas Pitre
2010-01-27  7:06     ` Patchdiff Bert Wesarg

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 NNTP newsgroup(s).