diff options
author | Thomas Rast <tr@thomasrast.ch> | 2013-11-22 17:29:16 +0100 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2013-11-27 12:16:49 -0800 |
commit | 7c801fbc74d4c4687ea6db60e24a67f896767824 (patch) | |
tree | 9c58bae06a4fc727824a3a787100441bb3472f51 /Documentation/git-rev-parse.txt | |
parent | doc: don't claim that cherry calls patch-id (diff) | |
download | tgif-7c801fbc74d4c4687ea6db60e24a67f896767824.tar.xz |
Documentation: 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 much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
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.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-rev-parse.txt')
0 files changed, 0 insertions, 0 deletions