{"thread":{"id":"33260","subject":"git merge heuristic","startedAt":"2013-03-22T18:53:04Z","lastAt":"2013-03-22T22:33:30Z","messageCount":2,"participants":["Senthil Natarajan","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211973","messageId":"ECEA5ACFB4B2BC4A81A93F032519ABCAD47F79@minsk.us.stoke.com","threadId":"33260","inReplyTo":null,"subject":"git merge heuristic","fromName":"Senthil Natarajan","fromEmail":"snatarajan@stoke.com","sentAt":"2013-03-22T18:53:04Z","receivedAt":"2013-03-22T18:53:04Z","isPatch":false,"sender":{"key":"snatarajan@stoke.com","avatar":null},"body":"Hi all,\n\nI want to learn about how Git compares patches while doing a merge.  For example, if a patch has been cherry-picked from branch A to branch B, and then downstream we do a \"git merge\" from A to B, how does Git know to skip the cherry-picked patch?  It would have a different SHA-1, so what is the comparison algorithm/heuristic?  What happens if the comment is different, but the actual patch is identical?\n\nI searched around, but couldn't find information on this.  I would appreciate it if someone could point me in the right direction.\n\nThanks!\n\n-Senthil\n"},{"id":"211998","messageId":"20130322223330.GB13207@sigill.intra.peff.net","threadId":"33260","inReplyTo":"ECEA5ACFB4B2BC4A81A93F032519ABCAD47F79@minsk.us.stoke.com","subject":"Re: git merge heuristic","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-22T22:33:30Z","receivedAt":"2013-03-22T22:33:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2013 at 11:53:04AM -0700, Senthil Natarajan wrote:\n\n> I want to learn about how Git compares patches while doing a merge. \n> For example, if a patch has been cherry-picked from branch A to branch\n> B, and then downstream we do a \"git merge\" from A to B, how does Git\n> know to skip the cherry-picked patch?\n\nIt doesn't. Git's 3-way merge only looks at three things: where each\nside of the merge ended, and what their common ancestor looked like.\n\nSo when you cherry-pick a commit, as long as the content in the file\nended up the same, there is no conflict. And it doesn't matter if it\nhappened by cherry-picking, or if you just happened to make a sequence\nof commits that ended in the same state.\n\nHowever, we do perform such detection during a rebase, in which we try\nto skip patches that have already been applied upstream.\n\n> It would have a different SHA-1, so what is the comparison\n> algorithm/heuristic?  What happens if the comment is different, but the\n> actual patch is identical?\n\nYes, the commit will have a different sha1. For that, we use the\n\"patch-id\", which is basically a sha of the contents of the diff of the\ncommit against its parent. See the manual for git-patch-id, git-cherry,\nand the --cherry-* options of \"git log\".\n\nIt will not find all duplicate commits (e.g., it will miss ones where\nthere was a conflict during cherry-pick, or even where the context is\nslightly different). However, in many cases, rebase can also realize\nwhile applying a patch that it has already been applied, and skip it\nthen.\n\n-Peff\n"}]}