threads / discuss / 5829

Could we please make "cherry-pick" not add the message by default?

Subject: Could we please make "cherry-pick" not add the message by default?

## tl;dr

4 messages between Oct 6, 2006 and Oct 6, 2006.

replies: 3people: 2as markdown or json

Linus Torvalds· Oct 6, 2006, 00:14 UTC · lore

It appears that more and more people are finding "git cherry-pick", and we now have a number of totally inane

	cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit

messages in the kernel logs, because I don't want to just re-cherry-pick them and edit peoples logs.

Those messages not only make no grammatical sense (you'd say "commit X" rather than "X commit"), but they have no point. The original commit is not reachable and makes no sense any more, and that's actually likely to always be the common case.

So could we just (a) fix the message word order to make sense and (b) make it only happen if people explicitly ask for it, rather than by default?

		Linus
Junio C Hamano· Oct 6, 2006, 00:35 UTC · re: Linus Torvalds · lore

Re: Could we please make "cherry-pick" not add the message by default?

Linus Torvalds <torvalds@osdl.org> writes:
Show 15 quoted lines
> It appears that more and more people are finding "git cherry-pick", and we 
> now have a number of totally inane
>
> 	cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit
>
> messages in the kernel logs, because I don't want to just re-cherry-pick 
> them and edit peoples logs.
>
> Those messages not only make no grammatical sense (you'd say "commit X" 
> rather than "X commit"), but they have no point. The original commit is 
> not reachable and makes no sense any more, and that's actually likely to 
> always be the common case.
>
> So could we just (a) fix the message word order to make sense and (b) make 
> it only happen if people explicitly ask for it, rather than by default?
Let's do (c) never show it and make -r a no-op.
Junio C Hamano· Oct 6, 2006, 00:56 UTC · re: Linus Torvalds · lore

[PATCH] cherry-pick: make -r the default

And introduce -x to expose (possibly) private commit object name for people who cherry-pick between public branches.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 * We discussed about this a few times already and every time I
   end up forgetting.  I noticed the topic on the kernel list a
   few days ago again.
   Thanks for reminding.  Does the rationale and warning for -x
   in the documentation look Ok?
 Documentation/git-cherry-pick.txt |   23 ++++++++++++++++-------
 git-revert.sh                     |   12 +++++++-----
 2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index bfa950c..875edb6 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change intro
 
 SYNOPSIS
 --------
-'git-cherry-pick' [--edit] [-n] [-r] <commit>
+'git-cherry-pick' [--edit] [-n] [-x] <commit>
 
 DESCRIPTION
 -----------
@@ -24,13 +24,22 @@ OPTIONS
 	With this option, `git-cherry-pick` will let you edit the commit
 	message prior committing.
 
--r|--replay::
-	Usually the command appends which commit was
+-x::
+	Cause the command to append which commit was
 	cherry-picked after the original commit message when
-	making a commit.  This option, '--replay', causes it to
-	use the original commit message intact.  This is useful
-	when you are reordering the patches in your private tree
-	before publishing.
+	making a commit.  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
+	maintenance branch for an older release from a
+	development branch), adding this information can be
+	useful.
+
+-r|--replay::
+	It used to be that the command defaulted to do `-x`
+	described above, and `-r` was to disable it.  Now the
+	default is not to do `-x` so this option is a no-op.
 
 -n|--no-commit::
 	Usually the command automatically creates a commit with
diff --git a/git-revert.sh b/git-revert.sh
index 2bf35d1..0784f74 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -12,13 +12,13 @@ case "$0" in
 *-cherry-pick* )
 	edit=
 	me=cherry-pick
-	USAGE='[--edit] [-n] [-r] <commit-ish>'  ;;
+	USAGE='[--edit] [-n] [-r] [-x] <commit-ish>'  ;;
 * )
 	die "What are you talking about?" ;;
 esac
 . git-sh-setup
 
-no_commit= replay=
+no_commit= replay=t
 while case "$#" in 0) break ;; esac
 do
 	case "$1" in
@@ -32,8 +32,10 @@ do
 	--n|--no|--no-|--no-e|--no-ed|--no-edi|--no-edit)
 		edit=
 		;;
-	-r|--r|--re|--rep|--repl|--repla|--replay)
-		replay=t
+	-r)
+		: no-op ;;
+	-x|--i-really-want-to-expose-my-private-commit-object-name)
+		replay=
 		;;
 	-*)
 		usage
@@ -121,7 +123,7 @@ cherry-pick)
 	git-cat-file commit $commit | sed -e '1,/^$/d'
 	case "$replay" in
 	'')
-		echo "(cherry picked from $commit commit)"
+		echo "(cherry picked from commit $commit)"
 		test "$rev" = "$commit" ||
 		echo "(original 'git cherry-pick' arguments: $@)"
 		;;
-- 
1.4.2.3.gae59
Linus Torvalds· Oct 6, 2006, 01:20 UTC · re: Junio C Hamano · lore

Re: [PATCH] cherry-pick: make -r the default

On Thu, 5 Oct 2006, Junio C Hamano wrote:
> 
>    Thanks for reminding.  Does the rationale and warning for -x
>    in the documentation look Ok?
Looks good, thanks.
		Linus

← back to recent threads