{"thread":{"id":"24257","subject":"Re: git cherry not marking commits with equivalent upstream","startedAt":"2010-07-01T19:38:45Z","lastAt":"2010-07-02T09:23:50Z","messageCount":13,"participants":["Andrew Pimlott","Björn Steinbrink","Jonathan Nieder","Junio C Hamano","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"144622","messageId":"1278012954-sup-3724@pimlott.net","threadId":"24257","inReplyTo":null,"subject":"git cherry not marking commits with equivalent upstream","fromName":"Andrew Pimlott","fromEmail":"andrew@pimlott.net","sentAt":"2010-07-01T19:38:45Z","receivedAt":"2010-07-01T19:38:45Z","isPatch":false,"sender":{"key":"andrew@pimlott.net","avatar":null},"body":"The documentation for git-cherry says it marks changes in the current\ncheckout that have an \"equivalent\" change in the upstream branch. It\neven says it's useful when feeding patches upstream by email instead of\ngit, which is what I'm doing (with CVS instead of email). But it\ndoesn't seem to work for me.\n\nI'll simulate cloning an upstream repo, creating and commiting a patch,\nthen sending it via email upstream to have it applied there, then\npulling the upstream commit (the upstream repo is a, mine is b):\n\n ~% mkdir a && cd a\n ~/a% git init\n Initialized empty Git repository in /home/andrew/a/.git/\n ~/a% touch a\n ~/a% git add a\n ~/a% git commit -m 1\n [master (root-commit) be4fa74] 1\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 a\n ~/a% git clone . ../b && cd ../b\n Initialized empty Git repository in /home/andrew/b/.git/\n ~/b% echo test > a\n ~/b% git add a\n ~/b% git commit -m 2\n [master 551e90a] 2\n 1 files changed, 1 insertions(+), 0 deletions(-)\n ~/b% cd ../a\n ~/a% echo test > a\n ~/a% git add a\n ~/a% git commit -m 3\n [master bb13e6c] 3\n 1 files changed, 1 insertions(+), 0 deletions(-)\n ~/a% cd ../b\n ~/b% git pull\n remote: Counting objects: 5, done.\n remote: Total 3 (delta 0), reused 0 (delta 0)\n Unpacking objects: 100% (3/3), done.\n From /home/andrew/a/.\n be4fa74..bb13e6c master -> origin/master\n Merge made by recursive.\n ~/b% cat a\n test\n\nNow, I think I have two equivalent commits in repo b, one of which came\nfrom repo a (upstream). So I expect git-cherry to show the other commit\nwith a '-' instead of a '+'. But no:\n\n ~/b% git log\n commit 27158bb3e5f7cf80a43eb7364a735f16c43e447c\n Merge: 551e90a bb13e6c\n Author: Andrew Pimlott \n Date: Thu Jul 1 12:25:21 2010 -0700\n\n Merge branch 'master' of /home/andrew/a/.\n\n commit bb13e6cea3a27a4450984b6d1d87f13d807d2d36\n Author: Andrew Pimlott \n Date: Thu Jul 1 12:25:18 2010 -0700\n\n 3\n\n commit 551e90ac390a2a27152661b9cbe73845d237e008\n Author: Andrew Pimlott \n Date: Thu Jul 1 12:25:06 2010 -0700\n\n 2\n\n commit be4fa741476176181947e96c5242003ffe4f4183\n Author: Andrew Pimlott \n Date: Thu Jul 1 12:24:42 2010 -0700\n\n 1\n ~/b% git show bb13e6cea3a27a4450984b6d1d87f13d807d2d36 | git patch-id\n 58105e2bbccf2799f480bf82bb76467ff0301c52 bb13e6cea3a27a4450984b6d1d87f13d807d2d36\n ~/b% git show 551e90ac390a2a27152661b9cbe73845d237e008 | git patch-id\n 58105e2bbccf2799f480bf82bb76467ff0301c52 551e90ac390a2a27152661b9cbe73845d237e008\n ~/b% git cherry\n + 551e90ac390a2a27152661b9cbe73845d237e008\n\nIs my undestanding of how this should work wrong? Is there any way to get\nthe result I want?\n\nAndrew\n(Please Cc me on replies)\n"},{"id":"144621","messageId":"1278013199-sup-487@pimlott.net","threadId":"24257","inReplyTo":"1278012954-sup-3724@pimlott.net","subject":"Re: git cherry not marking commits with equivalent upstream","fromName":"Andrew Pimlott","fromEmail":"andrew@pimlott.net","sentAt":"2010-07-01T19:40:40Z","receivedAt":"2010-07-01T19:40:40Z","isPatch":false,"sender":{"key":"andrew@pimlott.net","avatar":null},"body":"(forgot to mention I'm using git 1.7.1 from Debian package git-core\n1:1.7.1-1)\n"},{"id":"144636","messageId":"20100701204151.GA6354@atjola.homenet","threadId":"24257","inReplyTo":"1278012954-sup-3724@pimlott.net","subject":"Re: git cherry not marking commits with equivalent upstream","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2010-07-01T20:41:51Z","receivedAt":"2010-07-01T20:41:51Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2010.07.01 12:38:45 -0700, Andrew Pimlott wrote:\n> The documentation for git-cherry says it marks changes in the current\n> checkout that have an \"equivalent\" change in the upstream branch. It\n> even says it's useful when feeding patches upstream by email instead of\n> git, which is what I'm doing (with CVS instead of email). But it\n> doesn't seem to work for me.\n> \n> I'll simulate cloning an upstream repo, creating and commiting a patch,\n> then sending it via email upstream to have it applied there, then\n> pulling the upstream commit (the upstream repo is a, mine is b):\n> \n> ~% mkdir a && cd a\n> ~/a% git init\n> Initialized empty Git repository in /home/andrew/a/.git/\n> ~/a% touch a\n> ~/a% git add a\n> ~/a% git commit -m 1\n> [master (root-commit) be4fa74] 1\n> 0 files changed, 0 insertions(+), 0 deletions(-)\n> create mode 100644 a\n> ~/a% git clone . ../b && cd ../b\n> Initialized empty Git repository in /home/andrew/b/.git/\n> ~/b% echo test > a\n> ~/b% git add a\n> ~/b% git commit -m 2\n> [master 551e90a] 2\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n> ~/b% cd ../a\n> ~/a% echo test > a\n> ~/a% git add a\n> ~/a% git commit -m 3\n> [master bb13e6c] 3\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n> ~/a% cd ../b\n> ~/b% git pull\n> remote: Counting objects: 5, done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Unpacking objects: 100% (3/3), done.\n> From /home/andrew/a/.\n> be4fa74..bb13e6c master -> origin/master\n> Merge made by recursive.\n> ~/b% cat a\n> test\n\npull = fetch + merge, so your history in \"b\" looks like this:\n\n 2 (origin/master)\n / \\\n1 M (master)\n \\ /\n 3\n\nSo \"2\" is common to both branches and thus ignored by cherry. If you\njust fetch instead of merging, you get the result you expected:\n\ndoener@atjola:b (master) $ git fetch \nremote: Counting objects: 5, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom /home/doener/y/a\n 4815708..dfbbb81 master -> origin/master\n\ndoener@atjola:b (master) $ git cherry\n- 2544e5a7f5d6b545d9e24ba9dcac74861b0bf15c\n\nBut once I merge:\ndoener@atjola:b (master) $ git merge origin/master\nMerge made by recursive.\n\ndoener@atjola:b (master) $ git cherry\n+ 2544e5a7f5d6b545d9e24ba9dcac74861b0bf15c\n\nBjörn\n"},{"id":"144638","messageId":"20100701210919.GA4283@burratino","threadId":"24257","inReplyTo":"1278012954-sup-3724@pimlott.net","subject":"[PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-01T21:09:19Z","receivedAt":"2010-07-01T21:09:19Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Although ‘git cherry’ is advertised simply to list commits from\n that have not been merged into , internally it\nworks by checking for patches in .. that do not\nmatch a patch in ... This is fast because there\nare not many patches to check, and it makes sense semantically\nsince even if a new patch patches an old patch from ,\nit cannot be said to have been merged upstream unless it was\napplied there at some point after the and \nbranches diverged.\n\nBut. If the branch later merges from , it\nthrows a spanner in the works and for such a history ‘git cherry’\nis not very useful at all.\n\nExample:\n\n o---o---F---X'---G---U [upstream]\n \\ \\\n X----Y---M---T [topic]\n\nSuppose the author of the ‘topic’ branch starts from upstream\ncommit F and makes a few changes. One is applied upstream, and\nadditionally there is some other useful upstream change, so he\nperforms a merge to include the upstream updates into topic.\nThe expected output from ‘cherry’ is:\n\n + T\n + Y\n - X\n\nConsider the author of a different branch, also called ‘topic’, but\nthis one starts from commit G. Some infrastructure from an existing \nbranch is needed, so first she merges that. Then she adds her own\ncommit. The expected output from ‘cherry’ is:\n\n + T\n + Y\n + X\n\nsince none of the new commits have been applied upstream since\nthe fork point.\n\n‘cherry’ cannot distinguish between these two cases, in part because\nit does not distinguish between parents in a merge commit.\n\nAdd a BUGS section to explain the problem.\n\nReported-by: Frédéric Brière \nReported-by: Andrew Pimlott \nSigned-off-by: Jonathan Nieder \n---\nHi Andrew,\n\nAndrew Pimlott wrote:\n\n> The documentation for git-cherry says it marks changes in the current\n> checkout that have an \"equivalent\" change in the upstream branch. It\n> even says it's useful when feeding patches upstream by email instead of\n> git, which is what I'm doing (with CVS instead of email). But it\n> doesn't seem to work for me.\n[...]\n> ~/a% git commit -m 3\n> [master bb13e6c] 3\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n> ~/a% cd ../b\n> ~/b% git pull\n[...]\n> ~/b% git cherry\n> + 551e90ac390a2a27152661b9cbe73845d237e008\n\nI have not carefully read your example, but maybe this patch might help\nexplain it. A correct solution for some cases might include a\n‘git cherry --full’ option that scans the full upstream history for\nequivalents to patches.\n\nThoughts? Improvements?\n\n Documentation/git-cherry.txt | 15 +++++++++++++++\n 1 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex fed115a..83e3bdc 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -59,6 +59,21 @@ OPTIONS\n ::\n \tDo not report commits up to (and including) limit.\n \n+BUGS\n+----\n+'git cherry' does not cope well with merges from upstream on the\n+working branch. Any commits after the original fork point and\n+before the latest merge from upstream will be reported as not found\n+in .\n+\n+ ____*____*____*_____*__> \n+ / \\\n+ original fork point \\\n+ \\__+__+__+__+__+__+__+__*_> \n+\n+While these commits are part of upstream..head, their upstream\n+counterparts are not in head..upstream.\n+\n SEE ALSO\n --------\n linkgit:git-patch-id[1]\n-- \n1.7.1.1\n"},{"id":"144640","messageId":"1278017685-sup-6132@pimlott.net","threadId":"24257","inReplyTo":"20100701204151.GA6354@atjola.homenet","subject":"Re: git cherry not marking commits with equivalent upstream","fromName":"Andrew Pimlott","fromEmail":"andrew@pimlott.net","sentAt":"2010-07-01T21:17:01Z","receivedAt":"2010-07-01T21:17:01Z","isPatch":false,"sender":{"key":"andrew@pimlott.net","avatar":null},"body":"Excerpts from Björn Steinbrink's message of Thu Jul 01 13:41:51 -0700 2010:\n> pull = fetch + merge, so your history in \"b\" looks like this:\n> \n> 2 (origin/master)\n> / \\\n> 1 M (master)\n> \\ /\n> 3\n> \n> So \"2\" is common to both branches and thus ignored by cherry.\n\nOk, it's unintuitive to me that 2 is not considered part of the upstream\nbranch just because I've merged it into mine, but that explains it.\nThanks!\n\nHowever, I want to merge commits from upstream regularly and still\nfigure out what unmerged commits I have. So how can I make this use\ncase work? It sounds like I want to make git-cherry check against\neverything upstream since the fork point, not just what I haven't\nmerged. Would this be hard?\n\nAndrew\n"},{"id":"144642","messageId":"1278019489-sup-4929@pimlott.net","threadId":"24257","inReplyTo":"20100701210919.GA4283@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Andrew Pimlott","fromEmail":"andrew@pimlott.net","sentAt":"2010-07-01T21:33:18Z","receivedAt":"2010-07-01T21:33:18Z","isPatch":true,"sender":{"key":"andrew@pimlott.net","avatar":null},"body":"Excerpts from Jonathan Nieder's message of Thu Jul 01 14:09:19 -0700 2010:\n> Example:\n> \n> o---o---F---X'---G---U [upstream]\n> \\ \\\n> X----Y---M---T [topic]\n> \n> Suppose the author of the ‘topic’ branch starts from upstream\n> commit F and makes a few changes. One is applied upstream, and\n> additionally there is some other useful upstream change, so he\n> performs a merge to include the upstream updates into topic.\n> The expected output from ‘cherry’ is:\n> \n> + T\n> + Y\n> - X\n> \n> Consider the author of a different branch, also called ‘topic’, but\n> this one starts from commit G. Some infrastructure from an existing \n> branch is needed, so first she merges that. Then she adds her own\n> commit. The expected output from ‘cherry’ is:\n> \n> + T\n> + Y\n> + X\n> \n> since none of the new commits have been applied upstream since\n> the fork point.\n> \n> ‘cherry’ cannot distinguish between these two cases\n\nThanks for the awesome explanation! (I looked at the code but would not\nhave pulled this understanding.) I would still say the first output is\nthe more reasonable: it's more likely (in my estimate) the wanted\nresult, and in the case where it's not it's at least easily\ncomprehended. \n\nAnyway, the doc patch helps, and I would love git cherry --full.\n\nAndrew\n"},{"id":"144643","messageId":"20100701213512.GB4283@burratino","threadId":"24257","inReplyTo":"20100701210919.GA4283@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-01T21:35:12Z","receivedAt":"2010-07-01T21:35:12Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> it makes sense semantically\n> since even if a new patch patches an old patch from ,\n\nerr, for 'patches' read 'matches'. I was not trying to say\nsomething that complicated. :)\n\nSorry for the noise.\nJonathan\n"},{"id":"144645","messageId":"7vbpaq3glt.fsf@alter.siamese.dyndns.org","threadId":"24257","inReplyTo":"20100701210919.GA4283@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-01T23:52:14Z","receivedAt":"2010-07-01T23:52:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Example:\n>\n> o---o---F---X'---G---U [upstream]\n> \\ \\\n> X----Y---M---T [topic]\n>\n> Suppose the author of the ‘topic’ branch starts from upstream\n> commit F and makes a few changes. One is applied upstream, and\n> additionally there is some other useful upstream change, so he\n> performs a merge to include the upstream updates into topic.\n> The expected output from ‘cherry’ is:\n>\n> + T\n> + Y\n> - X\n>\n> Consider the author of a different branch, also called ‘topic’, but\n> this one starts from commit G. Some infrastructure from an existing \n> branch is needed, so first she merges that. Then she adds her own\n> commit.\n\nSorry, but it is unclear to me what kind of history you have in mind at\nthis point. What \"existing branch\" are you talking about? Presumably it\nis not the [topic] in an earlier example, nor it is [upstream] right?\n\no---o---o---o----G-------.---U [upstream]\n \\ \\ \n X---Y---M---T\n\nSomething like this?\n\n> The expected output from ‘cherry’ is:\n>\n> + T\n> + Y\n> + X\n>\n> since none of the new commits have been applied upstream since\n> the fork point.\n>\n> ‘cherry’ cannot distinguish between these two cases, in part because\n> it does not distinguish between parents in a merge commit.\n\nNow you completely lost me. I guess the biggest reason is you only talk\nabout \"the expected output\" without talking about \"what it actually\ngives\". Hence it is unclear what the significant difference \"between\nthese two cases\" you are trying to stress here.\n\n> Thoughts? Improvements?\n\nI think the actual patch text has the same problem. You say \"these\ncommits\" without saying which ones they are; perhaps saing \"the commits\nrepresented by asterisks in the picture\" or something may help, but I\ndunno.\n"},{"id":"144648","messageId":"20100702005147.GA5962@burratino","threadId":"24257","inReplyTo":"7vbpaq3glt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-02T00:51:47Z","receivedAt":"2010-07-02T00:51:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> Example:\n>>\n>> o---o---F---X'---G---U [upstream]\n>> \\ \\\n>> X----Y---M---T [topic]\n[...]\n>> Consider the author of a different branch, also called ‘topic’, but\n>> this one starts from commit G. Some infrastructure from an existing \n>> branch is needed, so first she merges that. Then she adds her own\n>> commit.\n>\n> Sorry, but it is unclear to me what kind of history you have in mind at\n> this point. What \"existing branch\" are you talking about? Presumably it\n> is not the [topic] in an earlier example, nor it is [upstream] right?\n> \n> o---o---o---o----G-------.---U [upstream]\n> \\ \\ \n> X---Y---M---T\n> \n> Something like this?\n\nSorry for the lack of clarity. The \"existing branch\" was the history\nending at commit Y in the original picture. The resulting topic would\nhave the shape of the branch labelled [topic] in my diagram.\n\nAnd except for the shapes being the same, this has nothing to do with\nthe earlier example.\n\nWhat I was trying to get at with the two examples is that in histories\nlike the above, the concept of \"fork point\" is not well defined.\nWhere did topic fork from upstream? It could have been at G, or F, or\nany other merge-base of upstream and topic for that matter; the\nrecorded history does not give enough information to say.\n\nThe choice of fork point might look like it is only for optimization,\nbut it affects the semantics, too.\n\nExample: reviving a reverted patch\n\n ... o---F---P---R---G---o [upstream]\n \\\n P' [alice]\n\nUpstream, a certain patch (P) was accepted, found to introduce horrible\nproblems, and then reverted (R). Patch submitter Alice still believes\nthat is a good patch, though, so she creates a branch to start work on\nit, cherry-picking the change (P'). ‘git cherry’ correctly reports\nP' as not merged upstream; that it has the same patch-id as commit P\nis simply irrelevant.\n\n $ git cherry\n + P'\n\nAlice might merge a branch with a fork point that does not have P as\nan ancestor:\n\n ... o---o---P---R---G---o [upstream]\n \\ /\n x\n / \\\n o P'\n / \\\n ... o---o---o---F---o---M [alice]\n\nHow can ‘git cherry’ tell that the fork point was G? That\nknowledge determines whether P' should be considered to be merged\nupstream or not:\n\n * If the fork point was F, then the patch for P' has been applied\n upstream since then (indirectly through the merge of G).\n\n * If the fork point is G, then the patch for P' was upstream all\n along, and P' has no upstream analog since then.\n\nIn reality, ‘git cherry’ does not choose; instead of doing arithmetic\nbased on fork points, it just says _no_ commit reachable from the tip\nof alice can be used as evidence that a patch from alice has been\nmerged.\n\nPlenty of other heuristics are possible, but it is hard to find a\nmore intuitive efficient one. I suspect I would find it useful to be\nable to explicitly set a commit ‘prefork’ and examine all commits\nprefork..upstream in the search for evidence that a patch has been\nmerged.\n"},{"id":"144650","messageId":"20100702010400.GA6058@burratino","threadId":"24257","inReplyTo":"20100701210919.GA4283@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-02T01:04:00Z","receivedAt":"2010-07-02T01:04:00Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> +'git cherry' does not cope well with merges from upstream on the\n> +working branch. Any commits after the original fork point and\n> +before the latest merge from upstream will be reported as not found\n> +in .\n> +\n> + ____*____*____*_____*__> \n> + / \\\n> + original fork point \\\n> + \\__+__+__+__+__+__+__+__*_> \n> +\n> +While these commits are part of upstream..head, their upstream\n> +counterparts are not in head..upstream.\n\nAs Junio mentioned, the text and diagram are hard to reconcile since\n“these commits” are not clearly explained to be “the commits after the\noriginal fork point and before the latest merge, marked with a +”.\n\nActually, the whole text is kind of awkward, which is why I left this\nhanging for so long[1]. Sorry.\n\nAdding “(marked +)” after “these commits” sounds reasonable to me as\na quick fix.\n\n[1] http://bugs.debian.org/575577\n"},{"id":"144667","messageId":"4C2D995D.2020708@drmicha.warpmail.net","threadId":"24257","inReplyTo":"20100701210919.GA4283@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-07-02T07:46:37Z","receivedAt":"2010-07-02T07:46:37Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jonathan Nieder venit, vidit, dixit 01.07.2010 23:09:\n> Although ‘git cherry’ is advertised simply to list commits from\n> that have not been merged into , internally it\n> works by checking for patches in .. that do not\n> match a patch in ... This is fast because there\n\n...and it says so in the very first line of the manpage.\n\n> are not many patches to check, and it makes sense semantically\n> since even if a new patch patches an old patch from ,\n> it cannot be said to have been merged upstream unless it was\n> applied there at some point after the and \n> branches diverged.\n> \n> But. If the branch later merges from , it\n> throws a spanner in the works and for such a history ‘git cherry’\n> is not very useful at all.\n\nI actually think I've reported this before, but I don't mind :)\nI keep (topic) branches for my git.git patches. git cherry is helpful\nhere. When a patch is applied, I merge the corresponding commit (i.e.\nJunio's version) to my topic branch to mark it as applied and to have a\nnice way of comparing the applied version to the submitted one. At that\npoint git cherry stops being useful.\n\n> \n> Example:\n> \n> o---o---F---X'---G---U [upstream]\n> \\ \\\n> X----Y---M---T [topic]\n> \n> Suppose the author of the ‘topic’ branch starts from upstream\n> commit F and makes a few changes. One is applied upstream, and\n> additionally there is some other useful upstream change, so he\n> performs a merge to include the upstream updates into topic.\n> The expected output from ‘cherry’ is:\n> \n> + T\n> + Y\n> - X\n> \n> Consider the author of a different branch, also called ‘topic’, but\n> this one starts from commit G. Some infrastructure from an existing \n> branch is needed, so first she merges that. Then she adds her own\n> commit. The expected output from ‘cherry’ is:\n> \n> + T\n> + Y\n> + X\n> \n> since none of the new commits have been applied upstream since\n> the fork point.\n> \n> ‘cherry’ cannot distinguish between these two cases, in part because\n> it does not distinguish between parents in a merge commit.\n> \n> Add a BUGS section to explain the problem.\n\nThis is not a bug. git cherry works exactly as described.\n\nAt worst, it is a misfeature.\n\ngit cherry would be more useful if you could specify a \"limit\" which is\nan ancestor of \"fork-point\", not only descendants.\n\n> \n> Thoughts? Improvements?\n\nAllow general \"limit\" :)\n\n> \n> Documentation/git-cherry.txt | 15 +++++++++++++++\n> 1 files changed, 15 insertions(+), 0 deletions(-)\n> \n> diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\n> index fed115a..83e3bdc 100644\n> --- a/Documentation/git-cherry.txt\n> +++ b/Documentation/git-cherry.txt\n> @@ -59,6 +59,21 @@ OPTIONS\n> ::\n> \tDo not report commits up to (and including) limit.\n> \n> +BUGS\n\n+DISCUSSION\n\n> +----\n> +'git cherry' does not cope well with merges from upstream on the\n> +working branch. Any commits after the original fork point and\n\n...which is the wrong way round anyways ;)\n\n> +before the latest merge from upstream will be reported as not found\n> +in .\n> +\n> + ____*____*____*_____*__> \n> + / \\\n> + original fork point \\\n> + \\__+__+__+__+__+__+__+__*_> \n> +\n> +While these commits are part of upstream..head, their upstream\n> +counterparts are not in head..upstream.\n\ngit-cherry(1) never speaks about upstream..head nor head..upstream. It\nuses \"fork-point\", and a merge creates a new \"fork-point\", i.e.\nmerge-base. I think it would be good to keep like that in order to avoid\nthat very misunderstanding. In fact, git cherry is about left and right\ncommits in upstream...head.\n\nThe second paragraph of \"DESCRIPTION\" may cause confusion when read\nwithout the first one, though.\n\nMichael\n"},{"id":"144669","messageId":"20100702081812.GA9219@burratino","threadId":"24257","inReplyTo":"4C2D995D.2020708@drmicha.warpmail.net","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-02T08:18:12Z","receivedAt":"2010-07-02T08:18:12Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n> Jonathan Nieder venit, vidit, dixit 01.07.2010 23:09:\n\n>> Add a BUGS section to explain the problem.\n>\n> This is not a bug. git cherry works exactly as described.\n> \n> At worst, it is a misfeature.\n\nUnix man pages have a history of using BUGS sections to describe\nmisfeatures and even unavoidable design constraints.\n\nOne nice effect is to encourage people to think of programs as\nfixable. But maybe it is bad PR. ;-)\n\n> git cherry would be more useful if you could specify a \"limit\" which is\n> an ancestor of \"fork-point\", not only descendants.\n>\n>> Thoughts? Improvements?\n>\n> Allow general \"limit\" :)\n\nHmm, I am not totally sure I understand. Conceptually ‘git cherry’\ncurrently does something like the following:\n\n 1. List all commits limit..head and find their patch ids\n (limit defaults to upstream if not specified)\n\n 2. List all commits head..upstream and find their patch ids\n\n 3. For each commit listed in step 1, check if it is in the\n list from step 2 and print its commit id with a + or -\n accordingly.\n\nAre you suggesting that the limit should replace head in\nstep 2? Or something else?\n\n> git-cherry(1) never speaks about upstream..head nor head..upstream. It\n> uses \"fork-point\", and a merge creates a new \"fork-point\", i.e.\n> merge-base.\n\nThis explanation becomes problematic when there is more than one merge-base:\nhttp://thread.gmane.org/gmane.comp.version-control.git/150067/focus=150093\n\nThank you for the comments. I considered using the argument\nto work around this but didn’t try the modification you suggest above.\nI would be happy to find that it works (generalized for repos with\na more shallow history to --full).\n\nSleepily,\nJonathan\n"},{"id":"144674","messageId":"4C2DB026.9050001@drmicha.warpmail.net","threadId":"24257","inReplyTo":"20100702081812.GA9219@burratino","subject":"Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-07-02T09:23:50Z","receivedAt":"2010-07-02T09:23:50Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jonathan Nieder venit, vidit, dixit 02.07.2010 10:18:\n> Michael J Gruber wrote:\n>> Jonathan Nieder venit, vidit, dixit 01.07.2010 23:09:\n> \n>>> Add a BUGS section to explain the problem.\n>>\n>> This is not a bug. git cherry works exactly as described.\n>>\n>> At worst, it is a misfeature.\n> \n> Unix man pages have a history of using BUGS sections to describe\n> misfeatures and even unavoidable design constraints.\n> \n> One nice effect is to encourage people to think of programs as\n> fixable. But maybe it is bad PR. ;-)\n> \n>> git cherry would be more useful if you could specify a \"limit\" which is\n>> an ancestor of \"fork-point\", not only descendants.\n>>\n>>> Thoughts? Improvements?\n>>\n>> Allow general \"limit\" :)\n> \n> Hmm, I am not totally sure I understand. Conceptually ‘git cherry’\n> currently does something like the following:\n> \n> 1. List all commits limit..head and find their patch ids\n> (limit defaults to upstream if not specified)\n> \n> 2. List all commits head..upstream and find their patch ids\n> \n> 3. For each commit listed in step 1, check if it is in the\n> list from step 2 and print its commit id with a + or -\n> accordingly.\n> \n> Are you suggesting that the limit should replace head in\n> step 2? Or something else?\n\nI suggest that I was reading limit on the wrong branch :|\nWhat I meant was specifiying a different lower limit in 2 would help:\nthen you could force git cherry to compare more commits, if you have a\nrough idea about how far to go back. But even being able to say\n\"v1.6.0..upstream\" here instead of head helps and is much more efficient\nthen going for --full.\n\n> \n>> git-cherry(1) never speaks about upstream..head nor head..upstream. It\n>> uses \"fork-point\", and a merge creates a new \"fork-point\", i.e.\n>> merge-base.\n> \n> This explanation becomes problematic when there is more than one merge-base:\n> http://thread.gmane.org/gmane.comp.version-control.git/150067/focus=150093\n\nI guess it always pays to read the full thread before jumping in... your\n\"prefork\" there is what I meant above.\n\nMichael\n"}]}