{"thread":{"id":"35374","subject":"[RFC PATCH] Revamp git-cherry(1)","startedAt":"2013-11-21T11:30:56Z","lastAt":"2013-11-22T19:39:09Z","messageCount":10,"participants":["Thomas Rast","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"230881","messageId":"3af3069696e3a59d513f1fef0ca797d103f6d882.1385033403.git.tr@thomasrast.ch","threadId":"35374","inReplyTo":null,"subject":"[RFC PATCH] Revamp git-cherry(1)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-21T11:30:56Z","receivedAt":"2013-11-21T11:30:56Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"git-cherry(1)'s \"description\" section has never really managed to\nexplain to me what the command does.  It contains too much explanation\nof the algorithm instead of simply saying what goals it achieves, and\ntoo much terminology that we otherwise do not use (fork-point instead\nof merge-base).\n\nTry a much more concise approach: state what it finds out, why this is\nneat, and how the output is formatted, in a few short paragraphs.  In\nreturn, provide a longer example of how it fits into a format-patch/am\nbased workflow.\n\nAlso carefully avoid using \"merge\" in a context where it does not mean\nsomething that comes from git-merge(1).  Instead, say \"apply\" in an\nattempt to further link to patch workflow concepts.\n\nWhile there, also omit the language about _which_ upstream branch we\ntreat as the default.  I literally just learned that we support having\nseveral, so let's not confuse new users here, especially considering\nthat git-config(1) does _not_ document this.\n\nPrompted-by: a.huemer@commend.com on #git\nSigned-off-by: Thomas Rast <tr@thomasrast.ch>\n---\n Documentation/git-cherry.txt | 73 +++++++++++++++++++++++++-------------------\n 1 file changed, 41 insertions(+), 32 deletions(-)\n\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex 2d0daae..78ffddf 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -3,7 +3,7 @@ git-cherry(1)\n \n NAME\n ----\n-git-cherry - Find commits not merged upstream\n+git-cherry - Find commits not applied in upstream\n \n SYNOPSIS\n --------\n@@ -12,46 +12,27 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-The changeset (or \"diff\") of each commit between the fork-point and <head>\n-is compared against each commit between the fork-point and <upstream>.\n-The diffs are compared after removing any whitespace and line numbers.\n+Determine whether there are commits in `<head>..<upstream>` that are\n+equivalent to those in the range `<limit>..<head>`.\n \n-Every commit that doesn't exist in the <upstream> branch\n-has its id (sha1) reported, prefixed by a symbol.  The ones that have\n-equivalent change already\n-in the <upstream> branch are prefixed with a minus (-) sign, and those\n-that only exist in the <head> branch are prefixed with a plus (+) symbol:\n-\n-               __*__*__*__*__> <upstream>\n-              /\n-    fork-point\n-              \\__+__+__-__+__+__-__+__> <head>\n-\n-\n-If a <limit> has been given then the commits along the <head> branch up\n-to and including <limit> are not reported:\n-\n-               __*__*__*__*__> <upstream>\n-              /\n-    fork-point\n-              \\__*__*__<limit>__-__+__> <head>\n-\n-\n-Because 'git cherry' compares the changeset rather than the commit id\n-(sha1), you can use 'git cherry' to find out if a commit you made locally\n-has been applied <upstream> under a different commit id.  For example,\n-this will happen if you're feeding patches <upstream> via email rather\n-than pushing or pulling commits directly.\n+The equivalence test is based on the diff, after removing whitespace\n+and line numbers.  git-cherry therefore detects when commits have been\n+\"copied\" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or\n+linkgit:git-rebase[1].\n \n+Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with\n+`-` for commits that have an equivalent in <upstream>, and `+` for\n+commits that do not.\n \n OPTIONS\n -------\n -v::\n-\tVerbose.\n+\tVerbose.  Currently shows the commit subjects next to their\n+\tSHA1.\n \n <upstream>::\n \tUpstream branch to compare against.\n-\tDefaults to the first tracked remote branch, if available.\n+\tDefaults to the upstream branch of HEAD.\n \n <head>::\n \tWorking branch; defaults to HEAD.\n@@ -59,6 +40,34 @@ OPTIONS\n <limit>::\n \tDo not report commits up to (and including) limit.\n \n+EXAMPLES\n+--------\n+\n+git-cherry is frequently used in patch-based workflows (see\n+linkgit:gitworkflows[7]) to determine if a series of patches has been\n+applied by the upstream maintainer.  In such a workflow you might\n+create and send a topic branch like this (fill in appropriate\n+arguments for `...`):\n++\n+------------\n+git checkout -b topic origin/master\n+# work and create some commits\n+git format-patch origin/master\n+git send-email ... 00*\n+------------\n++\n+Later, you can whether your changes have been applied by saying (still\n+on `topic`):\n++\n+------------\n+git fetch  # update your notion of origin/master\n+git cherry -v\n+------------\n++\n+Note that this uses , and assumes that\n+`core.autosetupmerge` is enabled (the default).\n+\n+\n SEE ALSO\n --------\n linkgit:git-patch-id[1]\n-- \n1.8.5.rc2.355.g6969a19\n"},{"id":"230884","messageId":"20131121115423.GC7171@sigill.intra.peff.net","threadId":"35374","inReplyTo":"3af3069696e3a59d513f1fef0ca797d103f6d882.1385033403.git.tr@thomasrast.ch","subject":"Re: [RFC PATCH] Revamp git-cherry(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-21T11:54:23Z","receivedAt":"2013-11-21T11:54:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 21, 2013 at 12:30:56PM +0100, Thomas Rast wrote:\n\n> git-cherry(1)'s \"description\" section has never really managed to\n> explain to me what the command does.  It contains too much explanation\n> of the algorithm instead of simply saying what goals it achieves, and\n> too much terminology that we otherwise do not use (fork-point instead\n> of merge-base).\n> \n> Try a much more concise approach: state what it finds out, why this is\n> neat, and how the output is formatted, in a few short paragraphs.  In\n> return, provide a longer example of how it fits into a format-patch/am\n> based workflow.\n\nFWIW, I find your concise explanation much friendlier.\n\n> +Later, you can whether your changes have been applied by saying (still\n> +on `topic`):\n\ns/can/& see/ ?\n\n> +------------\n> +git fetch  # update your notion of origin/master\n> +git cherry -v\n> +------------\n> ++\n> +Note that this uses , and assumes that\n> +`core.autosetupmerge` is enabled (the default).\n\nI couldn't quite parse this. Is there a word missing before the comma,\nor is it \"uses and assumes that...\"?\n\nGiven that it is the default, I wonder if it is worth mentioning at all.\nEven I, who knows what autosetupmerge does, took a minute to figure out\nwhy it is relevant here. I suspect it may just confuse most readers.\n\n-Peff\n"},{"id":"230896","messageId":"xmqqli0h4kvj.fsf@gitster.dls.corp.google.com","threadId":"35374","inReplyTo":"3af3069696e3a59d513f1fef0ca797d103f6d882.1385033403.git.tr@thomasrast.ch","subject":"Re: [RFC PATCH] Revamp git-cherry(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-21T19:26:08Z","receivedAt":"2013-11-21T19:26:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n>  NAME\n>  ----\n> -git-cherry - Find commits not merged upstream\n> +git-cherry - Find commits not applied in upstream\n\nGood.\n\n> +Determine whether there are commits in `<head>..<upstream>` that are\n> +equivalent to those in the range `<limit>..<head>`.\n>  \n> +The equivalence test is based on the diff, after removing whitespace\n> +and line numbers.  git-cherry therefore detects when commits have been\n> +\"copied\" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or\n> +linkgit:git-rebase[1].\n>  \n> +Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with\n> +`-` for commits that have an equivalent in <upstream>, and `+` for\n> +commits that do not.\n\nYeah, short-sweet-and-sufficient.\n\n>  OPTIONS\n>  -------\n>  -v::\n> -\tVerbose.\n> +\tVerbose.  Currently shows the commit subjects next to their\n> +\tSHA1.\n\nWhenever I see \"Currently\", it makes me wonder \"why does it need to\nsay that? Is there a plan to change it soon, and if so where is the\nplan described?\".\n\n> +EXAMPLES\n> +--------\n> +\n> +git-cherry is frequently used in patch-based workflows (see\n> +linkgit:gitworkflows[7]) to determine if a series of patches has been\n> +applied by the upstream maintainer.  In such a workflow you might\n> +create and send a topic branch like this (fill in appropriate\n> +arguments for `...`):\n\nI think the ASCII art commit graph that shows topology which we lost\nby this patch gave a more intiutive sense of what \"a topic branch\nlike this\" looked like than an incomplete skeleton of a command\nsequence that would be understood by those who already know how to\nwork with multiple branches.  Perhaps we want both?\n\nThanks.\n\n> ++\n> +------------\n> +git checkout -b topic origin/master\n> +# work and create some commits\n> +git format-patch origin/master\n> +git send-email ... 00*\n> +------------\n\n> +Later, you can whether your changes have been applied by saying (still\n> +on `topic`):\n> ++\n> +------------\n> +git fetch  # update your notion of origin/master\n> +git cherry -v\n> +------------\n> ++\n> +Note that this uses , and assumes that\n> +`core.autosetupmerge` is enabled (the default).\n> +\n> +\n>  SEE ALSO\n>  --------\n>  linkgit:git-patch-id[1]\n"},{"id":"230914","messageId":"874n754gkt.fsf@thomasrast.ch","threadId":"35374","inReplyTo":"20131121115423.GC7171@sigill.intra.peff.net","subject":"Re: [RFC PATCH] Revamp git-cherry(1)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-21T20:58:58Z","receivedAt":"2013-11-21T20:58:58Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Thu, Nov 21, 2013 at 12:30:56PM +0100, Thomas Rast wrote:\n>\n>> +Later, you can whether your changes have been applied by saying (still\n>> +on `topic`):\n>\n> s/can/& see/ ?\n>\n>> +Note that this uses , and assumes that\n>> +`core.autosetupmerge` is enabled (the default).\n>\n> I couldn't quite parse this. Is there a word missing before the comma,\n> or is it \"uses and assumes that...\"?\n\nI will just let this stand as evidence that I had a bad day.  Two\nsentences ruined by botched editing in all of five paragraphs.  Sheesh.\n\nThanks for reading carefully.\n\n> Given that it is the default, I wonder if it is worth mentioning at all.\n> Even I, who knows what autosetupmerge does, took a minute to figure out\n> why it is relevant here. I suspect it may just confuse most readers.\n\nOk, then let's remove it.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230915","messageId":"87pppt31v9.fsf@thomasrast.ch","threadId":"35374","inReplyTo":"xmqqli0h4kvj.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC PATCH] Revamp git-cherry(1)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-21T21:02:02Z","receivedAt":"2013-11-21T21:02:02Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>>  OPTIONS\n>>  -------\n>>  -v::\n>> -\tVerbose.\n>> +\tVerbose.  Currently shows the commit subjects next to their\n>> +\tSHA1.\n>\n> Whenever I see \"Currently\", it makes me wonder \"why does it need to\n> say that? Is there a plan to change it soon, and if so where is the\n> plan described?\".\n\nI wanted to avoid documenting exactly what it does, so that in the\nfuture it could do more than that.  Is that overly paranoid?\n\n>> +EXAMPLES\n>> +--------\n>> +\n>> +git-cherry is frequently used in patch-based workflows (see\n>> +linkgit:gitworkflows[7]) to determine if a series of patches has been\n>> +applied by the upstream maintainer.  In such a workflow you might\n>> +create and send a topic branch like this (fill in appropriate\n>> +arguments for `...`):\n>\n> I think the ASCII art commit graph that shows topology which we lost\n> by this patch gave a more intiutive sense of what \"a topic branch\n> like this\" looked like than an incomplete skeleton of a command\n> sequence that would be understood by those who already know how to\n> work with multiple branches.  Perhaps we want both?\n\nHmm.  I'll ponder for a moment and try to cook something up for v2.  I\ncan't say exactly what, but after initially trying to keep it, something\nfelt wrong to me about the ascii art.  Perhaps it's that it is only\nvaguely related to the actual output format.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230918","messageId":"xmqqwqk12yyz.fsf@gitster.dls.corp.google.com","threadId":"35374","inReplyTo":"87pppt31v9.fsf@thomasrast.ch","subject":"Re: [RFC PATCH] Revamp git-cherry(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-21T22:04:36Z","receivedAt":"2013-11-21T22:04:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>>>  OPTIONS\n>>>  -------\n>>>  -v::\n>>> -\tVerbose.\n>>> +\tVerbose.  Currently shows the commit subjects next to their\n>>> +\tSHA1.\n>>\n>> Whenever I see \"Currently\", it makes me wonder \"why does it need to\n>> say that? Is there a plan to change it soon, and if so where is the\n>> plan described?\".\n>\n> I wanted to avoid documenting exactly what it does, so that in the\n> future it could do more than that.  Is that overly paranoid?\n\nI would have to say so. After all, the documentation is supposed to\ndescribe the current state of affairs, and we would update it when\n\"the current state\" changes. In places, we may express our plan to\nforewarn readers of planned upcoming changes, but still...\n"},{"id":"230952","messageId":"dde93c10b7f6cb7b8cf94e9a0310c8e05aca2517.1385137650.git.tr@thomasrast.ch","threadId":"35374","inReplyTo":"xmqqli0h4kvj.fsf@gitster.dls.corp.google.com","subject":"[PATCH v2] Revamp git-cherry(1)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T16:29:16Z","receivedAt":"2013-11-22T16:29:16Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"git-cherry(1)'s \"description\" section has never really managed to\nexplain to me what the command does.  It contains too much explanation\nof the algorithm instead of simply saying what goals it achieves, and\ntoo much terminology that we otherwise do not use (fork-point instead\nof merge-base).\n\nTry a much more concise approach: state what it finds out, why this is\nneat, and how the output is formatted, in a few short paragraphs.  In\nreturn, provide much longer examples of how it fits into a\nformat-patch/am based workflow, and how it compares to reading the\nsame from git-log.\n\nAlso carefully avoid using \"merge\" in a context where it does not mean\nsomething that comes from git-merge(1).  Instead, say \"apply\" in an\nattempt to further link to patch workflow concepts.\n\nWhile there, also omit the language about _which_ upstream branch we\ntreat as the default.  I literally just learned that we support having\nseveral, so let's not confuse new users here, especially considering\nthat git-config(1) does _not_ document this.\n\nPrompted-by: a.huemer@commend.com on #git\nSigned-off-by: Thomas Rast <tr@thomasrast.ch>\n---\n\nJunio C Hamano wrote:\n> > +EXAMPLES\n> > +--------\n> > +\n> > +git-cherry is frequently used in patch-based workflows (see\n> > +linkgit:gitworkflows[7]) to determine if a series of patches has been\n> > +applied by the upstream maintainer.  In such a workflow you might\n> > +create and send a topic branch like this (fill in appropriate\n> > +arguments for `...`):\n> \n> I think the ASCII art commit graph that shows topology which we lost\n> by this patch gave a more intiutive sense of what \"a topic branch\n> like this\" looked like than an incomplete skeleton of a command\n> sequence that would be understood by those who already know how to\n> work with multiple branches.  Perhaps we want both?\n\nPerhaps like this?  I tried to tie in directly with what a user might\nsee from git-log.\n\nThis does push the ascii art rather far down in the manpage, but even\nwith a puny laptop display and a large font size the new EXAMPLES is\nwell on the first page of the manpage.  So the hope is that a\nstill-confused user would at least see that there are examples.\n\n\n Documentation/git-cherry.txt | 136 ++++++++++++++++++++++++++++++++-----------\n 1 file changed, 103 insertions(+), 33 deletions(-)\n\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex 2d0daae..6d14b3e 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -3,7 +3,7 @@ git-cherry(1)\n \n NAME\n ----\n-git-cherry - Find commits not merged upstream\n+git-cherry - Find commits not applied in upstream\n \n SYNOPSIS\n --------\n@@ -12,46 +12,26 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-The changeset (or \"diff\") of each commit between the fork-point and <head>\n-is compared against each commit between the fork-point and <upstream>.\n-The diffs are compared after removing any whitespace and line numbers.\n+Determine whether there are commits in `<head>..<upstream>` that are\n+equivalent to those in the range `<limit>..<head>`.\n \n-Every commit that doesn't exist in the <upstream> branch\n-has its id (sha1) reported, prefixed by a symbol.  The ones that have\n-equivalent change already\n-in the <upstream> branch are prefixed with a minus (-) sign, and those\n-that only exist in the <head> branch are prefixed with a plus (+) symbol:\n-\n-               __*__*__*__*__> <upstream>\n-              /\n-    fork-point\n-              \\__+__+__-__+__+__-__+__> <head>\n-\n-\n-If a <limit> has been given then the commits along the <head> branch up\n-to and including <limit> are not reported:\n-\n-               __*__*__*__*__> <upstream>\n-              /\n-    fork-point\n-              \\__*__*__<limit>__-__+__> <head>\n-\n-\n-Because 'git cherry' compares the changeset rather than the commit id\n-(sha1), you can use 'git cherry' to find out if a commit you made locally\n-has been applied <upstream> under a different commit id.  For example,\n-this will happen if you're feeding patches <upstream> via email rather\n-than pushing or pulling commits directly.\n+The equivalence test is based on the diff, after removing whitespace\n+and line numbers.  git-cherry therefore detects when commits have been\n+\"copied\" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or\n+linkgit:git-rebase[1].\n \n+Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with\n+`-` for commits that have an equivalent in <upstream>, and `+` for\n+commits that do not.\n \n OPTIONS\n -------\n -v::\n-\tVerbose.\n+\tShow the commit subjects next to the SHA1s.\n \n <upstream>::\n-\tUpstream branch to compare against.\n-\tDefaults to the first tracked remote branch, if available.\n+\tUpstream branch to search for equivalent commits.\n+\tDefaults to the upstream branch of HEAD.\n \n <head>::\n \tWorking branch; defaults to HEAD.\n@@ -59,6 +39,96 @@ OPTIONS\n <limit>::\n \tDo not report commits up to (and including) limit.\n \n+EXAMPLES\n+--------\n+\n+Patch workflows\n+~~~~~~~~~~~~~~~\n+\n+git-cherry is frequently used in patch-based workflows (see\n+linkgit:gitworkflows[7]) to determine if a series of patches has been\n+applied by the upstream maintainer.  In such a workflow you might\n+create and send a topic branch like this:\n+\n+------------\n+$ git checkout -b topic origin/master\n+# work and create some commits\n+$ git format-patch origin/master\n+$ git send-email ... 00*\n+------------\n+Later, you can see whether your changes have been applied by saying\n+(still on `topic`):\n+\n+------------\n+$ git fetch  # update your notion of origin/master\n+$ git cherry -v\n+------------\n+\n+Concrete example\n+~~~~~~~~~~~~~~~~\n+\n+In a situation where topic consisted of three commits, and the\n+maintainer applied two of them, the situation might look like:\n+\n+------------\n+$ git log --graph --oneline --decorate --boundary origin/master...topic\n+* 7654321 (origin/master) upstream tip commit\n+[... snip some other commits ...]\n+* cccc111 cherry-pick of C\n+* aaaa111 cherry-pick of A\n+[... snip a lot more that has happened ...]\n+| * cccc000 (topic) commit C\n+| * bbbb000 commit B\n+| * aaaa000 commit A\n+|/\n+o 1234567 branch point\n+------------\n+\n+In such cases, git-cherry shows a concise summary of what has been\n+applied:\n+\n+------------\n+$ git cherry origin/master topic\n+- cccc000... commit C\n++ bbbb000... commit B\n+- aaaa000... commit A\n+------------\n+\n+Using a limit\n+~~~~~~~~~~~~~\n+\n+The optional <limit> is useful in cases where your topic is based on\n+other work that is not in upstream.  Expanding on the previous\n+example, this might look like:\n+\n+------------\n+$ git log --graph --oneline --decorate --boundary origin/master...topic\n+* 7654321 (origin/master) upstream tip commit\n+[... snip some other commits ...]\n+* cccc111 cherry-pick of C\n+* aaaa111 cherry-pick of A\n+[... snip a lot more that has happened ...]\n+| * cccc000 (topic) commit C\n+| * bbbb000 commit B\n+| * aaaa000 commit A\n+| * 0000fff (base) unpublished stuff F\n+[... snip ...]\n+| * 0000aaa unpublished stuff A\n+|/\n+o 1234567 merge-base between upstream and topic\n+------------\n+\n+By specifying `base` as the limit, you can avoid listing commits\n+between `base` and `topic`:\n+\n+------------\n+$ git cherry origin/master topic base\n+- cccc000... commit C\n++ bbbb000... commit B\n+- aaaa000... commit A\n+------------\n+\n+\n SEE ALSO\n --------\n linkgit:git-patch-id[1]\n-- \n1.8.5.rc2.355.g6969a19\n"},{"id":"230963","messageId":"xmqqa9gw1bne.fsf@gitster.dls.corp.google.com","threadId":"35374","inReplyTo":"dde93c10b7f6cb7b8cf94e9a0310c8e05aca2517.1385137650.git.tr@thomasrast.ch","subject":"Re: [PATCH v2] Revamp git-cherry(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-22T19:25:57Z","receivedAt":"2013-11-22T19:25:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n>  NAME\n>  ----\n> +git-cherry - Find commits not applied in upstream\n>  \n> +Determine whether there are commits in `<head>..<upstream>` that are\n> +equivalent to those in the range `<limit>..<head>`.\n>  \n> +The equivalence test is based on the diff, after removing whitespace\n> +and line numbers.  git-cherry therefore detects when commits have been\n> +\"copied\" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or\n> +linkgit:git-rebase[1].\n>  \n> +Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with\n> +`-` for commits that have an equivalent in <upstream>, and `+` for\n> +commits that do not.\n\nThanks, this reads really much better than tha original.\n\nWe are listing those that need to be added to the upstream with \"+\",\nwhile listing those that can be dropped from yours if you rebase\nwith \"-\".  Hinting the rationale behind the choice of \"+/-\"\nsomewhere may help as a mnemonic to the readers (see below).\n\n> +EXAMPLES\n> +--------\n> +\n> +Patch workflows\n> +~~~~~~~~~~~~~~~\n> +\n> +git-cherry is frequently used in patch-based workflows (see\n> +linkgit:gitworkflows[7]) to determine if a series of patches has been\n> +applied by the upstream maintainer.  In such a workflow you might\n> +create and send a topic branch like this:\n> +\n> +------------\n> +$ git checkout -b topic origin/master\n> +# work and create some commits\n> +$ git format-patch origin/master\n> +$ git send-email ... 00*\n> +------------\n> +Later, you can see whether your changes have been applied by saying\n> +(still on `topic`):\n\nPerhaps we want a blank line before \"Later, ...\" to be consistent\nwith all the other displayed examples here (I'll squash it locally\nbefore queuing), even though AsciiDoc seems to format this just\nfine.\n\n> +\n> +------------\n> +$ git fetch  # update your notion of origin/master\n> +$ git cherry -v\n> +------------\n> +\n> +Concrete example\n> +~~~~~~~~~~~~~~~~\n\n\"A concrete example\", perhaps?  I dunno.\n\n> +In a situation where topic consisted of three commits, and the\n> +maintainer applied two of them, the situation might look like:\n> +\n> +------------\n> +$ git log --graph --oneline --decorate --boundary origin/master...topic\n> +* 7654321 (origin/master) upstream tip commit\n> +[... snip some other commits ...]\n> +* cccc111 cherry-pick of C\n> +* aaaa111 cherry-pick of A\n> +[... snip a lot more that has happened ...]\n> +| * cccc000 (topic) commit C\n> +| * bbbb000 commit B\n> +| * aaaa000 commit A\n> +|/\n> +o 1234567 branch point\n> +------------\n> +\n> +In such cases, git-cherry shows a concise summary of what has been\n> +applied:\n\nIt shows a concise summary of \"what has yet to be applied\" (to be\nconsistent with the one-line description in the NAME section).\n\n> +------------\n> +$ git cherry origin/master topic\n> +- cccc000... commit C\n> ++ bbbb000... commit B\n> +- aaaa000... commit A\n> +------------\n\nAnd the earlier \"why +/-\" could be done after this picture,\nperhaps like:\n\n\tHere, we see that the commits A and C (marked with `-`) can\n\tbe dropped from your `topic` branch when you rebase it on\n\ttop of `origin/master`, while the commit B (marked with `+`)\n\tstill needs to be kept so that it will be sent to be applied\n\tto `origin/master`.\n\nor somesuch?\n"},{"id":"230965","messageId":"87li0gi5xx.fsf@linux-k42r.v.cablecom.net","threadId":"35374","inReplyTo":"xmqqa9gw1bne.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2] Revamp git-cherry(1)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T19:37:14Z","receivedAt":"2013-11-22T19:37:14Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> We are listing those that need to be added to the upstream with \"+\",\n> while listing those that can be dropped from yours if you rebase\n> with \"-\".  Hinting the rationale behind the choice of \"+/-\"\n> somewhere may help as a mnemonic to the readers (see below).\n[...]\n> And the earlier \"why +/-\" could be done after this picture,\n> perhaps like:\n>\n> \tHere, we see that the commits A and C (marked with `-`) can\n> \tbe dropped from your `topic` branch when you rebase it on\n> \ttop of `origin/master`, while the commit B (marked with `+`)\n> \tstill needs to be kept so that it will be sent to be applied\n> \tto `origin/master`.\n>\n> or somesuch?\n\nGood idea, thanks.  Will integrate this more \"what still needs to be\nintegrated\"-minded wording into a v3.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230966","messageId":"xmqqy54gz0o2.fsf@gitster.dls.corp.google.com","threadId":"35374","inReplyTo":"87li0gi5xx.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH v2] Revamp git-cherry(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-22T19:39:09Z","receivedAt":"2013-11-22T19:39:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> We are listing those that need to be added to the upstream with \"+\",\n>> while listing those that can be dropped from yours if you rebase\n>> with \"-\".  Hinting the rationale behind the choice of \"+/-\"\n>> somewhere may help as a mnemonic to the readers (see below).\n> [...]\n>> And the earlier \"why +/-\" could be done after this picture,\n>> perhaps like:\n>>\n>> \tHere, we see that the commits A and C (marked with `-`) can\n>> \tbe dropped from your `topic` branch when you rebase it on\n>> \ttop of `origin/master`, while the commit B (marked with `+`)\n>> \tstill needs to be kept so that it will be sent to be applied\n>> \tto `origin/master`.\n>>\n>> or somesuch?\n>\n> Good idea, thanks.  Will integrate this more \"what still needs to be\n> integrated\"-minded wording into a v3.\n\nJust to possibly save one round-trip, here is what I tentatively\nqueued on top of yours.\n\n Documentation/git-cherry.txt | 13 ++++++++++---\n 1 file changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex 6d14b3e..0ea921a 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -3,7 +3,7 @@ git-cherry(1)\n \n NAME\n ----\n-git-cherry - Find commits not applied in upstream\n+git-cherry - Find commits yet to be applied to upstream\n \n SYNOPSIS\n --------\n@@ -56,6 +56,7 @@ $ git checkout -b topic origin/master\n $ git format-patch origin/master\n $ git send-email ... 00*\n ------------\n+\n Later, you can see whether your changes have been applied by saying\n (still on `topic`):\n \n@@ -84,8 +85,8 @@ $ git log --graph --oneline --decorate --boundary origin/master...topic\n o 1234567 branch point\n ------------\n \n-In such cases, git-cherry shows a concise summary of what has been\n-applied:\n+In such cases, git-cherry shows a concise summary of what has yet to\n+be applied:\n \n ------------\n $ git cherry origin/master topic\n@@ -94,6 +95,12 @@ $ git cherry origin/master topic\n - aaaa000... commit A\n ------------\n \n+Here, we see that the commits A and C (marked with `-`) can be\n+dropped from your `topic` branch when you rebase it on top of\n+`origin/master`, while the commit B (marked with `+`) still needs to\n+be kept so that it will be sent to be applied to `origin/master`.\n+\n+\n Using a limit\n ~~~~~~~~~~~~~\n \n-- \n1.8.5-rc3-362-gdf10213\n"}]}