On Wednesday 22-August-2012 10:55:29 Jonathan del Strother wrote:
> On 22 August 2012 17:58, Junio C Hamano <gits...@pobox.com> wrote:
> > Jonathan del Strother <maill...@steelskies.com> writes:
> >> On 22 August 2012 13:10, Brian Foster <brian.fos...@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!


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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to