On Wednesday 22-August-2012 10:55:29 Jonathan del Strother wrote: > On 22 August 2012 17:58, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jonathan del Strother <maillist@xxxxxxxxxxxxxx> writes: > >> On 22 August 2012 13:10, Brian Foster <brian.foster@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html