[PATCH] git-cherry-pick: improve description of -x.
- From
- Ralf Wildenhues <ralf.wildenhues@gmx.de>
- Date
- Oct 19, 2007, 17:41 UTC
- Message-ID
- <20071019174134.GD9906@ins.uni-bonn.de>
Reword the first sentence of the description of -x, in order to make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> ---
I have two issues with "git-cherry-pick -x": When reading its manpage description for the first time, I completely failed to understand the first sentence, and had to try it out in order to understand.
Further, I am surprised that -x seems to be nonfunctional when the
cherry pick introduces a conflict. Example:
git init
echo >dummy
git add dummy
git commit -m dummy
git checkout -b br
echo one >file
git add file
git commit -m one
echo two >>file
git commit -a -m two
git checkout master
git cherry-pick -x br # conflict, tells me "-c ..." arg to use
# for the commit later
echo '1d
w' | ed file # resolve conflict
git add file
git commit -c ...The prototype commit message now does not contain the | (cherry picked from commit ...).
Is that by design (because there were conflicts) or an omission? In case of the former, maybe the description of -x should mention this.
Thanks, Ralf
Documentation/git-cherry-pick.txt | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 47b1e8c..c7d83ce 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -27,10 +27,10 @@ OPTIONS message prior committing. -x:: - Cause the command to append which commit was - cherry-picked after the original commit message when - making a commit. Do not use this option if you are - cherry-picking from your private branch because the + When recording the commit, the original commit message will + be appended with a note that indicates which commit this + change was cherry-picked from. Do not use this option if + you are cherry-picking from your private branch because the information is useless to the recipient. If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a
-- 1.5.3.1.153.g89df5