[RFC PATCH] Revamp git-cherry(1)
git-cherry(1)'s description section has never really managed to explain to me what the command does. It contains too much explanation of the algorithm instead of simply saying what goals it achieves, and too much terminology that we otherwise do not use (fork-point instead of merge-base). Try a much more concise approach: state what it finds out, why this is neat, and how the output is formatted, in a few short paragraphs. In return, provide a longer example of how it fits into a format-patch/am based workflow. Also carefully avoid using merge in a context where it does not mean something that comes from git-merge(1). Instead, say apply in an attempt to further link to patch workflow concepts. While there, also omit the language about _which_ upstream branch we treat as the default. I literally just learned that we support having several, so let's not confuse new users here, especially considering that git-config(1) does _not_ document this. Prompted-by: a.hue...@commend.com on #git Signed-off-by: Thomas Rast t...@thomasrast.ch --- Documentation/git-cherry.txt | 73 +--- 1 file changed, 41 insertions(+), 32 deletions(-) diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt index 2d0daae..78ffddf 100644 --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -3,7 +3,7 @@ git-cherry(1) NAME -git-cherry - Find commits not merged upstream +git-cherry - Find commits not applied in upstream SYNOPSIS @@ -12,46 +12,27 @@ SYNOPSIS DESCRIPTION --- -The changeset (or diff) of each commit between the fork-point and head -is compared against each commit between the fork-point and upstream. -The diffs are compared after removing any whitespace and line numbers. +Determine whether there are commits in `head..upstream` that are +equivalent to those in the range `limit..head`. -Every commit that doesn't exist in the upstream branch -has its id (sha1) reported, prefixed by a symbol. The ones that have -equivalent change already -in the upstream branch are prefixed with a minus (-) sign, and those -that only exist in the head branch are prefixed with a plus (+) symbol: - - __*__*__*__*__ upstream - / -fork-point - \__+__+__-__+__+__-__+__ head - - -If a limit has been given then the commits along the head branch up -to and including limit are not reported: - - __*__*__*__*__ upstream - / -fork-point - \__*__*__limit__-__+__ head - - -Because 'git cherry' compares the changeset rather than the commit id -(sha1), you can use 'git cherry' to find out if a commit you made locally -has been applied upstream under a different commit id. For example, -this will happen if you're feeding patches upstream via email rather -than pushing or pulling commits directly. +The equivalence test is based on the diff, after removing whitespace +and line numbers. git-cherry therefore detects when commits have been +copied by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or +linkgit:git-rebase[1]. +Outputs the SHA1 of every commit in `limit..head`, prefixed with +`-` for commits that have an equivalent in upstream, and `+` for +commits that do not. OPTIONS --- -v:: - Verbose. + Verbose. Currently shows the commit subjects next to their + SHA1. upstream:: Upstream branch to compare against. - Defaults to the first tracked remote branch, if available. + Defaults to the upstream branch of HEAD. head:: Working branch; defaults to HEAD. @@ -59,6 +40,34 @@ OPTIONS limit:: Do not report commits up to (and including) limit. +EXAMPLES + + +git-cherry is frequently used in patch-based workflows (see +linkgit:gitworkflows[7]) to determine if a series of patches has been +applied by the upstream maintainer. In such a workflow you might +create and send a topic branch like this (fill in appropriate +arguments for `...`): ++ + +git checkout -b topic origin/master +# work and create some commits +git format-patch origin/master +git send-email ... 00* + ++ +Later, you can whether your changes have been applied by saying (still +on `topic`): ++ + +git fetch # update your notion of origin/master +git cherry -v + ++ +Note that this uses , and assumes that +`core.autosetupmerge` is enabled (the default). + + SEE ALSO linkgit:git-patch-id[1] -- 1.8.5.rc2.355.g6969a19 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revamp git-cherry(1)
On Thu, Nov 21, 2013 at 12:30:56PM +0100, Thomas Rast wrote: git-cherry(1)'s description section has never really managed to explain to me what the command does. It contains too much explanation of the algorithm instead of simply saying what goals it achieves, and too much terminology that we otherwise do not use (fork-point instead of merge-base). Try a much more concise approach: state what it finds out, why this is neat, and how the output is formatted, in a few short paragraphs. In return, provide a longer example of how it fits into a format-patch/am based workflow. FWIW, I find your concise explanation much friendlier. +Later, you can whether your changes have been applied by saying (still +on `topic`): s/can/ see/ ? + +git fetch # update your notion of origin/master +git cherry -v + ++ +Note that this uses , and assumes that +`core.autosetupmerge` is enabled (the default). I couldn't quite parse this. Is there a word missing before the comma, or is it uses and assumes that...? Given that it is the default, I wonder if it is worth mentioning at all. Even I, who knows what autosetupmerge does, took a minute to figure out why it is relevant here. I suspect it may just confuse most readers. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revamp git-cherry(1)
Thomas Rast t...@thomasrast.ch writes: Junio C Hamano gits...@pobox.com writes: OPTIONS --- -v:: - Verbose. + Verbose. Currently shows the commit subjects next to their + SHA1. Whenever I see Currently, it makes me wonder why does it need to say that? Is there a plan to change it soon, and if so where is the plan described?. I wanted to avoid documenting exactly what it does, so that in the future it could do more than that. Is that overly paranoid? I would have to say so. After all, the documentation is supposed to describe the current state of affairs, and we would update it when the current state changes. In places, we may express our plan to forewarn readers of planned upcoming changes, but still... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revamp git-cherry(1)
Thomas Rast t...@thomasrast.ch writes: NAME -git-cherry - Find commits not merged upstream +git-cherry - Find commits not applied in upstream Good. +Determine whether there are commits in `head..upstream` that are +equivalent to those in the range `limit..head`. +The equivalence test is based on the diff, after removing whitespace +and line numbers. git-cherry therefore detects when commits have been +copied by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or +linkgit:git-rebase[1]. +Outputs the SHA1 of every commit in `limit..head`, prefixed with +`-` for commits that have an equivalent in upstream, and `+` for +commits that do not. Yeah, short-sweet-and-sufficient. OPTIONS --- -v:: - Verbose. + Verbose. Currently shows the commit subjects next to their + SHA1. Whenever I see Currently, it makes me wonder why does it need to say that? Is there a plan to change it soon, and if so where is the plan described?. +EXAMPLES + + +git-cherry is frequently used in patch-based workflows (see +linkgit:gitworkflows[7]) to determine if a series of patches has been +applied by the upstream maintainer. In such a workflow you might +create and send a topic branch like this (fill in appropriate +arguments for `...`): I think the ASCII art commit graph that shows topology which we lost by this patch gave a more intiutive sense of what a topic branch like this looked like than an incomplete skeleton of a command sequence that would be understood by those who already know how to work with multiple branches. Perhaps we want both? Thanks. ++ + +git checkout -b topic origin/master +# work and create some commits +git format-patch origin/master +git send-email ... 00* + +Later, you can whether your changes have been applied by saying (still +on `topic`): ++ + +git fetch # update your notion of origin/master +git cherry -v + ++ +Note that this uses , and assumes that +`core.autosetupmerge` is enabled (the default). + + SEE ALSO linkgit:git-patch-id[1] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revamp git-cherry(1)
Junio C Hamano gits...@pobox.com writes: OPTIONS --- -v:: -Verbose. +Verbose. Currently shows the commit subjects next to their +SHA1. Whenever I see Currently, it makes me wonder why does it need to say that? Is there a plan to change it soon, and if so where is the plan described?. I wanted to avoid documenting exactly what it does, so that in the future it could do more than that. Is that overly paranoid? +EXAMPLES + + +git-cherry is frequently used in patch-based workflows (see +linkgit:gitworkflows[7]) to determine if a series of patches has been +applied by the upstream maintainer. In such a workflow you might +create and send a topic branch like this (fill in appropriate +arguments for `...`): I think the ASCII art commit graph that shows topology which we lost by this patch gave a more intiutive sense of what a topic branch like this looked like than an incomplete skeleton of a command sequence that would be understood by those who already know how to work with multiple branches. Perhaps we want both? Hmm. I'll ponder for a moment and try to cook something up for v2. I can't say exactly what, but after initially trying to keep it, something felt wrong to me about the ascii art. Perhaps it's that it is only vaguely related to the actual output format. -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revamp git-cherry(1)
Jeff King p...@peff.net writes: On Thu, Nov 21, 2013 at 12:30:56PM +0100, Thomas Rast wrote: +Later, you can whether your changes have been applied by saying (still +on `topic`): s/can/ see/ ? +Note that this uses , and assumes that +`core.autosetupmerge` is enabled (the default). I couldn't quite parse this. Is there a word missing before the comma, or is it uses and assumes that...? I will just let this stand as evidence that I had a bad day. Two sentences ruined by botched editing in all of five paragraphs. Sheesh. Thanks for reading carefully. Given that it is the default, I wonder if it is worth mentioning at all. Even I, who knows what autosetupmerge does, took a minute to figure out why it is relevant here. I suspect it may just confuse most readers. Ok, then let's remove it. -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
