On Wednesday 22-August-2012 10:55:29 Jonathan del Strother wrote:
> On 22 August 2012 17:58, Junio C Hamano <[email protected]> wrote:
> > Jonathan del Strother <[email protected]> writes:
> >> On 22 August 2012 13:10, Brian Foster <[email protected]> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
