{"thread":{"id":"31314","subject":"[Q] Comparing differences introduced by two commits?","startedAt":"2012-08-22T12:10:12Z","lastAt":"2012-08-24T08:52:37Z","messageCount":5,"participants":["Brian Foster","Jonathan del Strother","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197578","messageId":"2794881.R5SsgFdXjR@laclwks004","threadId":"31314","inReplyTo":null,"subject":"[Q] Comparing differences introduced by two commits?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-08-22T12:10:12Z","receivedAt":"2012-08-22T12:10:12Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"\nHello,\n\n I have two commits A and B. They are on separate branches.\n Commit A is a older version of B. I want to see what, if\n any, differences there are between what commit A changes\n and what commit B changes. (The relative positions of\n two commits may also differ in the two branches; that is, \n there may have been some commit re-ordering.)\n\n Ideally, the contents of the commit-message are also taken\n into account (albeit things like the commit-Id, dates, and\n so on will differ and therefore should be ignored).\n\n I realize the history leading up to each commit can itself\n cause what the commits change to differ, even if the \"net\n result\" of the two commits is the same. For my purposes,\n this is a noise issue, and I'm happy to consider A and B \n as not causing the same changes (i.e., as being different),\n albeit if the only difference is the line numbers, then it\n would be nice to ignore that.\n\n In the past I've done:\n\n diff <(git show A) <(git show B)\n\n which produces rather messy output but is Ok when dealing\n with just one or two sets of A/B commits. I now have a\n large-ist set of A/B commits, and the above is impractical.\n\n Some searching hasn't found any suggestions I'm too happy\n with, albeit I've very possibly overlooked something.\n\n Any suggestions?\ncheers!\n\t-blf-\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"},{"id":"197589","messageId":"CAF5DW8L=6wn6wumzwJuC=QMkb3ggZoPxOJrZf=FQEdArwNzzdw@mail.gmail.com","threadId":"31314","inReplyTo":"2794881.R5SsgFdXjR@laclwks004","subject":"Re: [Q] Comparing differences introduced by two commits?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2012-08-22T15:15:52Z","receivedAt":"2012-08-22T15:15:52Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On 22 August 2012 13:10, Brian Foster wrote:\n>\n> Hello,\n>\n> I have two commits A and B. They are on separate branches.\n> Commit A is a older version of B. I want to see what, if\n> any, differences there are between what commit A changes\n> and what commit B changes. (The relative positions of\n> two commits may also differ in the two branches; that is,\n> there may have been some commit re-ordering.)\n>\n> Ideally, the contents of the commit-message are also taken\n> into account (albeit things like the commit-Id, dates, and\n> so on will differ and therefore should be ignored).\n>\n> I realize the history leading up to each commit can itself\n> cause what the commits change to differ, even if the \"net\n> result\" of the two commits is the same. For my purposes,\n> this is a noise issue, and I'm happy to consider A and B\n> as not causing the same changes (i.e., as being different),\n> albeit if the only difference is the line numbers, then it\n> would be nice to ignore that.\n>\n> In the past I've done:\n>\n> diff <(git show A) <(git show B)\n>\n> which produces rather messy output but is Ok when dealing\n> with just one or two sets of A/B commits. I now have a\n> large-ist set of A/B commits, and the above is impractical.\n>\n> Some searching hasn't found any suggestions I'm too happy\n> with, albeit I've very possibly overlooked something.\n\nWhat about cherry picking B onto A, then showing the cherry-picked commit?\n\nOff the top of my head :\n\ngit checkout A\ngit cherry-pick B\ngit show HEAD\n\n-Jonathan\n"},{"id":"197596","messageId":"7vharuamok.fsf@alter.siamese.dyndns.org","threadId":"31314","inReplyTo":"CAF5DW8L=6wn6wumzwJuC=QMkb3ggZoPxOJrZf=FQEdArwNzzdw@mail.gmail.com","subject":"Re: [Q] Comparing differences introduced by two commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-22T16:58:19Z","receivedAt":"2012-08-22T16:58:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan del Strother writes:\n\n> On 22 August 2012 13:10, Brian Foster wrote:\n> ...\n>> In the past I've done:\n>>\n>> diff <(git show A) <(git show B)\n>>\n>> which produces rather messy output but is Ok when dealing\n>> with just one or two sets of A/B commits. I now have a\n>> large-ist set of A/B commits, and the above is impractical.\n\nIsn't this what interdiff is for?\n\n>> Some searching hasn't found any suggestions I'm too happy\n>> with, albeit I've very possibly overlooked something.\n>\n> What about cherry picking B onto A, then showing the cherry-picked commit?\n>\n> Off the top of my head :\n>\n> git checkout A\n> git cherry-pick B\n> git show HEAD\n\nWouldn't you see a lot of needless conflicts while doing such a cherry-pick?\n\nI often do\n\n\tgit checkout A^\n git cherry-pick B\n git diff A\n\nwhen queuing an updated patch.\n"},{"id":"197615","messageId":"CAF5DW8J8JL-jGexh+CmmCafFAREjAJrb8zzOwP8b9fEuqUB56w@mail.gmail.com","threadId":"31314","inReplyTo":"7vharuamok.fsf@alter.siamese.dyndns.org","subject":"Re: [Q] Comparing differences introduced by two commits?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2012-08-22T17:55:29Z","receivedAt":"2012-08-22T17:55:29Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On 22 August 2012 17:58, Junio C Hamano wrote:\n> Jonathan del Strother writes:\n>\n>> On 22 August 2012 13:10, Brian Foster wrote:\n>> ...\n>>> In the past I've done:\n>>>\n>>> diff <(git show A) <(git show B)\n>>>\n>>> which produces rather messy output but is Ok when dealing\n>>> with just one or two sets of A/B commits. I now have a\n>>> large-ist set of A/B commits, and the above is impractical.\n>\n> Isn't this what interdiff is for?\n>\n>>> Some searching hasn't found any suggestions I'm too happy\n>>> with, albeit I've very possibly overlooked something.\n>>\n>> What about cherry picking B onto A, then showing the cherry-picked commit?\n>>\n>> Off the top of my head :\n>>\n>> git checkout A\n>> git cherry-pick B\n>> git show HEAD\n>\n> Wouldn't you see a lot of needless conflicts while doing such a cherry-pick?\n>\n> I often do\n>\n> git checkout A^\n> git cherry-pick B\n> git diff A\n>\n> when queuing an updated patch.\n>\n\nTrue. That sounds a better solution.\n"},{"id":"197755","messageId":"5720224.TlUPhgDYky@laclwks004","threadId":"31314","inReplyTo":"CAF5DW8J8JL-jGexh+CmmCafFAREjAJrb8zzOwP8b9fEuqUB56w@mail.gmail.com","subject":"Re: [Q] Comparing differences introduced by two commits?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-08-24T08:52:37Z","receivedAt":"2012-08-24T08:52:37Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"On Wednesday 22-August-2012 10:55:29 Jonathan del Strother wrote:\n> On 22 August 2012 17:58, Junio C Hamano wrote:\n> > Jonathan del Strother writes:\n> >> On 22 August 2012 13:10, Brian Foster wrote:\n> >> ...\n> >>> In the past I've done:\n> >>>\n> >>> diff <(git show A) <(git show B)\n> >>>\n> >>> which produces rather messy output [...]\n> >\n> > Isn't this what interdiff is for?\n\n I'd never(?) heard of interdiff(1) — THANKS!\n With my current problem it produces (1) Some false results,\n and (2) Gets enough patch-rejects so as to be useful only\n in getting a 10km-high overview. Nonetheless, it's a help.\n\n> >>> Some searching hasn't found any suggestions I'm too happy\n> >>> with, albeit I've very possibly overlooked something.\n> >>\n> >> What about cherry picking B onto A, then showing the cherry-picked commit?\n> >>[...]\n> > I often do\n> >\n> > git checkout A^\n> > git cherry-pick B\n> > git diff A\n> >\n> > when queuing an updated patch.\n\n This works fairly well. I get conflicts (not surprising),\n which _probably_ corrolate rather well to the interdiff\n patch-rejects (not checked), but the advantage here is I\n can easily see what's going on (what the conflict _is_).\n\n Neither compares commit-comments, but that is a obviously\n a scriptable problem.\n\n As it so happens, it turns out my number of A/B pairs is\n rather less than expected (c.50 not the estimated c.90),\n of which c.10 get cherry-pick conflicts. So the problem\n is now looking quite tractable. Thanks for the help!\n\ncheers,\n\t-blf-\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"}]}