summaryrefslogtreecommitdiff
path: root/builtin/reflog.c
diff options
context:
space:
mode:
authorLibravatar Thomas Rast <tr@thomasrast.ch>2013-11-22 17:29:16 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2013-11-27 12:16:49 -0800
commit7c801fbc74d4c4687ea6db60e24a67f896767824 (patch)
tree9c58bae06a4fc727824a3a787100441bb3472f51 /builtin/reflog.c
parentdoc: don't claim that cherry calls patch-id (diff)
downloadtgif-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 'builtin/reflog.c')
0 files changed, 0 insertions, 0 deletions