{"thread":{"id":"10879","subject":"[Discussion] cherry-picking a merge","startedAt":"2007-11-15T08:00:45Z","lastAt":"2007-11-15T17:40:22Z","messageCount":3,"participants":["Junio C Hamano","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"59943","messageId":"7v3av86iqa.fsf@gitster.siamese.dyndns.org","threadId":"10879","inReplyTo":null,"subject":"[Discussion] cherry-picking a merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T08:00:45Z","receivedAt":"2007-11-15T08:00:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier \"git cherry-pick\" learned the \"-m <parent-number>\"\noption to allow cherry-picking a merge commit.\n\nWhen you have this history:\n\n  ---o---o---C---A---M\n      \\             /\n       o---o-------B\n\nYou can replay the change between A and M (in other words, the\neffect of merging B into A) on top of C to create a new commit,\nwith:\n\n        $ git cherry-pick -m 1 M\n\nIn the current implementation, the resulting commit has a single\nparent C.  This is quite similar to a squash merge of B into C.\n\nWhen you think about it, as long as the topological relationship\nbetween A and B is very similar to that of C and B (iow,\n\"merge-base A B\" and \"merge-base C B\" are the same), the effect\nshould be the same as a real merge between B and C, shouldn't it?\n\n  ---o---o---C---A---M\n      \\       \\     /\n       o---o---\\---B\n                \\   \\\n                 `---X\n\nI am wondering if it makes sense to record the result of\n\"cherry-pick -m\" as a real merge between the current HEAD and\nall the other parents of the cherry-picked merge except the one\nthat is named with the <parent-number>.\n"},{"id":"59946","messageId":"20071115081648.GK14735@spearce.org","threadId":"10879","inReplyTo":"7v3av86iqa.fsf@gitster.siamese.dyndns.org","subject":"Re: [Discussion] cherry-picking a merge","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-15T08:16:49Z","receivedAt":"2007-11-15T08:16:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> You can replay the change between A and M (in other words, the\n> effect of merging B into A) on top of C to create a new commit,\n> with:\n> \n>         $ git cherry-pick -m 1 M\n> \n> In the current implementation, the resulting commit has a single\n> parent C.  This is quite similar to a squash merge of B into C.\n> \n> When you think about it, as long as the topological relationship\n> between A and B is very similar to that of C and B (iow,\n> \"merge-base A B\" and \"merge-base C B\" are the same), the effect\n> should be the same as a real merge between B and C, shouldn't it?\n> \n>   ---o---o---C---A---M\n>       \\       \\     /\n>        o---o---\\---B\n>                 \\   \\\n>                  `---X\n> \n> I am wondering if it makes sense to record the result of\n> \"cherry-pick -m\" as a real merge between the current HEAD and\n> all the other parents of the cherry-picked merge except the one\n> that is named with the <parent-number>.\n\nYes.\n\nThen `rebase -i` might be able to learn how to \"pick\" merge commits.\nAnd then my coworkers can stop bothering me about that.  And just\ndo it themselves.\n\nI used to think of merges as something special.  I now really only\nlook at them as being special *during* the merge process, as you\nmay need to generate that recursive base.  But otherwise its just\n\"diff M^1..M\".  So why isn't it?\n\n:-)\n\n-- \nShawn.\n"},{"id":"60007","messageId":"7vy7cz4dbt.fsf@gitster.siamese.dyndns.org","threadId":"10879","inReplyTo":"20071115081648.GK14735@spearce.org","subject":"Re: [Discussion] cherry-picking a merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T17:40:22Z","receivedAt":"2007-11-15T17:40:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> When you think about it, as long as the topological relationship\n>> between A and B is very similar to that of C and B (iow,\n>> \"merge-base A B\" and \"merge-base C B\" are the same), the effect\n>> should be the same as a real merge between B and C, shouldn't it?\n>> \n>>   ---o---o---C---A---M\n>>       \\       \\     /\n>>        o---o---\\---B\n>>                 \\   \\\n>>                  `---X\n>> \n>> I am wondering if it makes sense to record the result of\n>> \"cherry-pick -m\" as a real merge between the current HEAD and\n>> all the other parents of the cherry-picked merge except the one\n>> that is named with the <parent-number>.\n>\n> Yes.\n\nActually, this turns to be a trick question ;-)\n\nIf there was an accidental clean merge between A and B, and a\npart of the duplicated same changes in the accidental clean\nmerge sits between C and A, replaying the difference from A to M\non top of C would not yield the same result as merging B into C.\n"}]}