{"thread":{"id":"19312","subject":"Cherry woes","startedAt":"2009-05-12T13:15:05Z","lastAt":"2009-05-12T17:57:32Z","messageCount":2,"participants":["Michael J Gruber","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113632","messageId":"4A097659.4060507@drmicha.warpmail.net","threadId":"19312","inReplyTo":null,"subject":"Cherry woes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-12T13:15:05Z","receivedAt":"2009-05-12T13:15:05Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Hi there\n\nI encountered a misfeature of cherry or misuse of it by myself... Also,\nthe behaviour is not quite what the doc suggests. The script below\ngenerates the following DAG:\n\n*   05f4f8c (refs/heads/master) Merge branch 'upstream'\n|\\\n| * 2c8fad1 (refs/heads/upstream) add a\n* | df7b5e4 Add a\n|/\n* 6bdebf5 init\n\nNaively, one would say that master and upstream contain one commit each\nwhich differ but their patch-ids coincide (see below). That's the same\nsituation before as well as after the merge.\n\nBut calling \"git cherry -v upstream\" when on the master branch gives\ndifferent results:\n\nBefore merge:\n- df7b5e472d9a23d02943b331a7dc9ec638f44b33 Add a\nMerge made by recursive.\nAfter merge:\n+ df7b5e472d9a23d02943b331a7dc9ec638f44b33 Add a\n\nOf course master contains both 2c8fad1 and df7b5e4, and upstream only\nthe latter (Did I say \"naively\"?). But still upstream contains a commit\nwhich is patch-equivalent to 2c8fad1, and which git cherry does not find.\n\nThe point is that \"git cherry upstream head\" looks at each commit in\nupstream..head and checks whether there is an equivalent patch in\nhead..upstream. (This differs from the doc which says fork-point..head\nresp. fork-point..upstream.)\n\nIn the DAG above, all is well when head is master^ (df7b5e4), i.e.\nbefore the merge, but head..upstream is empty after the merge.\n\nNow, adjusting the doc is easy, but I still feel that cherry does not\ngive the most useful info in the situation at hand. But how would I find\na better lower boundary for the range ..upstream? merge-base of master\nand upstream is upstream so that doesn't cut it. So I'm wondering what\nthe right approach is and whether anyone cares.\n\nMichael\n\n--->%---\n#!/bin/bash\n\nrm -Rf cherrybug\nmkdir cherrybug && cd cherrybug && git init\necho a > a && git add a && git commit -m init\ngit checkout -b upstream\necho b >> a && git add a && git commit -m \"add a\"\ngit checkout master\necho b >> a && git add a && git commit -m \"Add a\"\necho \"Before merge:\"\ngit cherry -v upstream\ngit merge upstream\necho \"After merge:\"\ngit cherry -v upstream\n"},{"id":"113676","messageId":"32541b130905121057s19f9dd42h566a017d47bfe865@mail.gmail.com","threadId":"19312","inReplyTo":"4A097659.4060507@drmicha.warpmail.net","subject":"Re: Cherry woes","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-05-12T17:57:32Z","receivedAt":"2009-05-12T17:57:32Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, May 12, 2009 at 9:15 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Now, adjusting the doc is easy, but I still feel that cherry does not\n> give the most useful info in the situation at hand. But how would I find\n> a better lower boundary for the range ..upstream? merge-base of master\n> and upstream is upstream so that doesn't cut it. So I'm wondering what\n> the right approach is and whether anyone cares.\n\nI think the problem is that there's no well-defined \"furthest back\"\nplace where a particular patch might already exist in upstream.\nPerhaps it was placed in upstream three years ago.\n\nMy guess is git-cherry was designed for a primarily rebase-like\nworkflow.  In that case, you would *never* merge between the two\nbranches in question, so the fork-point (ie. merge-base) would be the\nright thing to use, as git-cherry already seems to do.\n\nAha, and the git changelog seems to support this theory, as we can see\nby the first mention of git-cherry in\n93c36dcd0a4f6373e3a02a8505046801106ddb85:\n\n    [PATCH] git-cherry: find commits not merged upstream.\n\n    The git-cherry command helps the git-rebase script by finding\n    commits that have not been merged upstream.  Commits already\n    included in upstream are prefixed with '-' (meaning \"drop from\n    my local pull\"), while commits missing from upstream are\n    prefixed with '+' (meaning \"add to the updated upstream\").\n\nSo my conclusion: git cherry is not really compatible with git merge.\nIts man page could probably use a clarification to this effect.\n\nHave fun,\n\nAvery\n"}]}