[Q] Comparing differences introduced by two commits?

[Q] Comparing differences introduced by two commits?

[Brian Foster]

Hello,

 I have two commits A and B.  They are on separate branches.
 Commit A is a older version of B.  I want to see what, if
 any, differences there are between what commit A changes
 and what commit B changes.  (The relative positions of
 two commits may also differ in the two branches; that is, 
 there may have been some commit re-ordering.)

 Ideally, the contents of the commit-message are also taken
 into account (albeit things like the commit-Id, dates, and
 so on will differ and therefore should be ignored).

 I realize the history leading up to each commit can itself
 cause what the commits change to differ, even if the "net
 result" of the two commits is the same.  For my purposes,
 this is a noise issue, and I'm happy to consider A and B 
 as not causing the same changes (i.e., as being different),
 albeit if the only difference is the line numbers, then it
 would be nice to ignore that.

 In the past I've done:

    diff <(git show A) <(git show B)

 which produces rather messy output but is Ok when dealing
 with just one or two sets of A/B commits.  I now have a
 large-ist set of A/B commits, and the above is impractical.

 Some searching hasn't found any suggestions I'm too happy
 with, albeit I've very possibly overlooked something.

 Any suggestions?
cheers!
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: [Q] Comparing differences introduced by two commits?

[Jonathan del Strother]

On 22 August 2012 13:10, Brian Foster <brian.foster@maxim-ic.com> wrote:
>
> Hello,
>
>  I have two commits A and B.  They are on separate branches.
>  Commit A is a older version of B.  I want to see what, if
>  any, differences there are between what commit A changes
>  and what commit B changes.  (The relative positions of
>  two commits may also differ in the two branches; that is,
>  there may have been some commit re-ordering.)
>
>  Ideally, the contents of the commit-message are also taken
>  into account (albeit things like the commit-Id, dates, and
>  so on will differ and therefore should be ignored).
>
>  I realize the history leading up to each commit can itself
>  cause what the commits change to differ, even if the "net
>  result" of the two commits is the same.  For my purposes,
>  this is a noise issue, and I'm happy to consider A and B
>  as not causing the same changes (i.e., as being different),
>  albeit if the only difference is the line numbers, then it
>  would be nice to ignore that.
>
>  In the past I've done:
>
>     diff <(git show A) <(git show B)
>
>  which produces rather messy output but is Ok when dealing
>  with just one or two sets of A/B commits.  I now have a
>  large-ist set of A/B commits, and the above is impractical.
>
>  Some searching hasn't found any suggestions I'm too happy
>  with, albeit I've very possibly overlooked something.

What about cherry picking B onto A, then showing the cherry-picked commit?

Off the top of my head :

git checkout A
git cherry-pick B
git show HEAD

-Jonathan

Re: [Q] Comparing differences introduced by two commits?

[Junio C Hamano]

Jonathan del Strother <maillist@steelskies.com> writes:

> On 22 August 2012 13:10, Brian Foster <brian.foster@maxim-ic.com> wrote:
> ...
>>  In the past I've done:
>>
>>     diff <(git show A) <(git show B)
>>
>>  which produces rather messy output but is Ok when dealing
>>  with just one or two sets of A/B commits.  I now have a
>>  large-ist set of A/B commits, and the above is impractical.

Isn't this what interdiff is for?

>>  Some searching hasn't found any suggestions I'm too happy
>>  with, albeit I've very possibly overlooked something.
>
> What about cherry picking B onto A, then showing the cherry-picked commit?
>
> Off the top of my head :
>
> git checkout A
> git cherry-pick B
> git show HEAD

Wouldn't you see a lot of needless conflicts while doing such a cherry-pick?

I often do

	git checkout A^
        git cherry-pick B
        git diff A

when queuing an updated patch.

Re: [Q] Comparing differences introduced by two commits?

[Jonathan del Strother]

On 22 August 2012 17:58, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan del Strother <maillist@steelskies.com> writes:
>
>> On 22 August 2012 13:10, Brian Foster <brian.foster@maxim-ic.com> wrote:
>> ...
>>>  In the past I've done:
>>>
>>>     diff <(git show A) <(git show B)
>>>
>>>  which produces rather messy output but is Ok when dealing
>>>  with just one or two sets of A/B commits.  I now have a
>>>  large-ist set of A/B commits, and the above is impractical.
>
> Isn't this what interdiff is for?
>
>>>  Some searching hasn't found any suggestions I'm too happy
>>>  with, albeit I've very possibly overlooked something.
>>
>> What about cherry picking B onto A, then showing the cherry-picked commit?
>>
>> Off the top of my head :
>>
>> git checkout A
>> git cherry-pick B
>> git show HEAD
>
> Wouldn't you see a lot of needless conflicts while doing such a cherry-pick?
>
> I often do
>
>         git checkout A^
>         git cherry-pick B
>         git diff A
>
> when queuing an updated patch.
>

True.  That sounds a better solution.

Re: [Q] Comparing differences introduced by two commits?

[Brian Foster]

On Wednesday 22-August-2012 10:55:29 Jonathan del Strother wrote:
> On 22 August 2012 17:58, Junio C Hamano <gitster@pobox.com> wrote:
> > Jonathan del Strother <maillist@steelskies.com> writes:
> >> On 22 August 2012 13:10, Brian Foster <brian.foster@maxim-ic.com> wrote:
> >> ...
> >>>  In the past I've done:
> >>>
> >>>     diff <(git show A) <(git show B)
> >>>
> >>>  which produces rather messy output [...]
> >
> > Isn't this what interdiff is for?

 I'd never(?) heard of interdiff(1) —  THANKS!
 With my current problem it produces  (1) Some false results,
 and  (2) Gets enough patch-rejects so as to be useful only
 in getting a 10km-high overview.   Nonetheless, it's a help.

> >>>  Some searching hasn't found any suggestions I'm too happy
> >>>  with, albeit I've very possibly overlooked something.
> >>
> >> What about cherry picking B onto A, then showing the cherry-picked commit?
> >>[...]
> > I often do
> >
> >         git checkout A^
> >         git cherry-pick B
> >         git diff A
> >
> > when queuing an updated patch.

 This works fairly well.  I get conflicts (not surprising),
 which _probably_ corrolate rather well to the interdiff
 patch-rejects (not checked), but the advantage here is I
 can easily see what's going on (what the conflict _is_).

 Neither compares commit-comments, but that is a obviously
 a scriptable problem.

 As it so happens, it turns out my number of A/B pairs is
 rather less than expected (c.50 not the estimated c.90),
 of which c.10 get cherry-pick conflicts.  So the problem
 is now looking quite tractable.  Thanks for the help!

cheers,
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/