[PATCH] cherry-pick: Add an option to prepend a string to the commit message

This can be useful situations where you have a batch of commits to
cherry-pick and need to prefix each new commit message with similar
information (such as the subversion revision, when used in conjunction
with git-svn).

Signed-off-by: Bobby Powers <redacted>
---
 Documentation/git-cherry-pick.txt |    7 +++++++
 builtin/revert.c                  |    8 +++++++-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index d71607a..2526e13 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt

@@ -62,6 +62,13 @@ OPTIONS
 	option is used, your index does not have to match the
 	HEAD commit.  The cherry-pick is done against the
 	beginning state of your index.
+
+--prepend::
+	Specify a string to prepend to the commit message.  This
+	can be useful situations where you have a batch of commits
+	to cherry-pick and need to prefix each new commit message
+	with similar information (such as the subversion revision,
+	when used in conjunction with git-svn).
 +
 This is useful when cherry-picking more than one commits'
 effect to your index in a row.

diff --git a/builtin/revert.c b/builtin/revert.c
index 7976b5a..45091ac 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c

@@ -44,6 +44,7 @@ static int allow_rerere_auto;
 
 static const char *me;
 static const char *strategy;
+static const char *prepend;
 
 #define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
 

@@ -64,7 +65,7 @@ static void parse_args(int argc, const char **argv)
 		OPT_INTEGER('m', "mainline", &mainline, "parent number"),
 		OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
 		OPT_STRING(0, "strategy", &strategy, "strategy", "merge strategy"),
-		OPT_END(),
+		OPT_STRING(0, "prepend", &prepend, "message", "string to prepend to the commit message"),
 		OPT_END(),
 		OPT_END(),
 	};

@@ -392,6 +393,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
 			die("cherry-pick --ff cannot be used with -x");
 		if (edit)
 			die("cherry-pick --ff cannot be used with --edit");
+		if (prepend)
+			die("cherry-pick --ff cannot be used with --prepend");
 	}
 
 	if (read_cache() < 0)

@@ -482,6 +485,9 @@ static int revert_or_cherry_pick(int argc, const char **argv)
 		next = commit;
 		next_label = msg.label;
 		set_author_ident_env(msg.message);
+		if (prepend) {
+			strbuf_addstr(&msgbuf, prepend);
+		}
 		add_message_to_msg(&msgbuf, msg.message);
 		if (no_replay) {
 			strbuf_addstr(&msgbuf, "(cherry picked from commit ");

-- 
1.7.1.251.g92a7.dirty

Bobby Powers wrote:

This can be useful situations where you have a batch of commits to
cherry-pick and need to prefix each new commit message with similar
information

Sounds reasonable.

Cc-ing Christian who is closer to an area expert.

(such as the subversion revision, when used in conjunction
with git-svn).

Could you give an example?  I am imagining

  git cherry-pick --prepend='r3815: ' HEAD..svn/Trunk

but I haven’t figured out the context.

The patch itself is clean.  Two tiny nitpicks:

This adds an option to cherry-pick and revert...

[...]

... and implements it only for cherry-pick (with unnecessary braces).

I would be interested to hear from those who might know whether
something generic like the applypatch-msg hook could work (which is
not to say a convenient command-line option would not be handy to have
in addition to that.)

Jonathan

On Sat, Jun 12, 2010 at 12:58:32AM -0500, Jonathan Nieder wrote:

I would be interested to hear from those who might know whether
something generic like the applypatch-msg hook could work (which is
not to say a convenient command-line option would not be handy to have
in addition to that.)

What bothers me is how specific this munging is. What if I want to
append to the message? Or put something after the subject line, but
before the commit body? Or add a pseudo-header (like signed-off-by) to
the set of pseudo-headers at the end, properly adding a newline if it is
the first such pseudo-header.

FWIW, we can already do this kind of stuff with:

  GIT_EDITOR="sed -i 1i$prefix" git cherry-pick -e $ref

or

  git cherry-pick -n $ref &&
  sed -i 1i$prefix .git/MERGE_MSG
  GIT_EDITOR=true git commit

I'll admit the first one is not very intuitive. But it is easy to script
around the second form. For one of my examples, I would probably do:

  git cherry-pick -n $ref &&
  git log -1 --format='%s%n%ncontent between subject and body%n%b' |
  git commit -F -

The specifics aren't important, but I think you can see that the "don't
commit automatically, make a message as you like, and then use the
regular message-specifiers for commit to commit it" technique is pretty
straightforward and very flexible.

It's obviously more typing for occasional interactive use, but in that
case, why not just use "git cherry-pick -e" and use your editor?

-Peff

On 06/11/2010 11:28 PM, Jeff King wrote:

On Sat, Jun 12, 2010 at 12:58:32AM -0500, Jonathan Nieder wrote:

quoted

I would be interested to hear from those who might know whether
something generic like the applypatch-msg hook could work (which is
not to say a convenient command-line option would not be handy to have
in addition to that.)

What bothers me is how specific this munging is. What if I want to
append to the message? Or put something after the subject line, but
before the commit body? Or add a pseudo-header (like signed-off-by) to
the set of pseudo-headers at the end, properly adding a newline if it is
the first such pseudo-header.

What prompted this was a large project I had checked out through 
git-svn.  I had made a number of commits to trunk, interspersed with 
other dev's work.  I needed to cherry-pick my work into a stable branch, 
but each commit needed to start with 'cherry-pick rXXX:', where XXX was 
the subversion commit number.

My solution was the following:

$ git checkout $RELEASE_BRANCH
$ export WHAT="my-subsystem:"
$ export SINCE="Jun 1 2010"
$ for i in `git log --grep="$WHAT" --oneline master --after="$SINCE" \
             | cut -d ' ' -f 1 | tac`;                                \
       do git cherry-pick $i -x                                       \
              --prepend "cherry pick r$(echo $(git log -1 $i) | perl  \
                                   -pe 's|.*/trunk@(\d+).*|\1|'): ";  \
   done

but, as you point out, I could have accomplished the same thing through 
other means.

FWIW, we can already do this kind of stuff with:

   GIT_EDITOR="sed -i 1i$prefix" git cherry-pick -e $ref

or

   git cherry-pick -n $ref&&
   sed -i 1i$prefix .git/MERGE_MSG
   GIT_EDITOR=true git commit

I'll admit the first one is not very intuitive. But it is easy to script
around the second form. For one of my examples, I would probably do:

   git cherry-pick -n $ref&&
   git log -1 --format='%s%n%ncontent between subject and body%n%b' |
   git commit -F -

I like this; it clearly hadn't occurred to me.  I can just use this 
format instead.

yours,
Bobby

The specifics aren't important, but I think you can see that the "don't
commit automatically, make a message as you like, and then use the
regular message-specifiers for commit to commit it" technique is pretty
straightforward and very flexible.

It's obviously more typing for occasional interactive use, but in that
case, why not just use "git cherry-pick -e" and use your editor?

-Peff

Bobby Powers wrote:

On 06/11/2010 11:28 PM, Jeff King wrote:

quoted

FWIW, we can already do this kind of stuff with:

  GIT_EDITOR="sed -i 1i$prefix" git cherry-pick -e $ref

or

  git cherry-pick -n $ref&&
  sed -i 1i$prefix .git/MERGE_MSG
  GIT_EDITOR=true git commit

I'll admit the first one is not very intuitive. But it is easy to script
around the second form. For one of my examples, I would probably do:

  git cherry-pick -n $ref&&
  git log -1 --format='%s%n%ncontent between subject and body%n%b' |
  git commit -F -

I like this; it clearly hadn't occurred to me.  I can just use this
format instead.

Sorry to misunderstand.  Maybe something like this could help.  Patch
applies on top of cc/cherry-pick-series.

-- %< --
Subject: Documentation: explain use of cherry-pick -n in scripts

Add an example to indicate how to munge a commit while cherry-picking it.

The formatting is ugly because I do not know how to ask asciidoc to
use a multiline heading in a definition list.

Based-on-work-by: Jeff King [off-list ref]
Signed-off-by: Jonathan Nieder <redacted>
---

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index bcb4c75..4769ca5 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt

@@ -113,6 +113,17 @@ git cherry-pick --ff ..next::
 	are in next but not HEAD to the current branch, creating a new
 	commit for each new change.
 
+------------
+git checkout maint &&
+git cherry-pick -n bugfix &&
+git add new_file.txt &&
+git show -s bugfix --format='%s%n%n%b%n%nAlso add a new file.' |
+git commit -F -
+------------
+
+	Apply a bugfix on top of the maint branch and tweak it before
+	creating a new commit to record it.
+
 Author
 ------
 Written by Junio C Hamano <gitster@pobox.com>

-- 

On Sat, Jun 12, 2010 at 02:18:50AM -0500, Jonathan Nieder wrote:

Subject: Documentation: explain use of cherry-pick -n in scripts

Add an example to indicate how to munge a commit while cherry-picking it.

The formatting is ugly because I do not know how to ask asciidoc to
use a multiline heading in a definition list.

I don't think there is a way to do what you want. Even an explicit " +"
at the end of line, which is supposed to cause a line-break, doesn't
seem to work.

However, I wonder if all of the examples should actually be in "----"
listing blocks. That would generally render them in a monospaced
typewriter font (though in the manpage, it doesn't matter much), and
your multiline addition would be rendered properly, too.

+------------
+git checkout maint &&
+git cherry-pick -n bugfix &&
+git add new_file.txt &&
+git show -s bugfix --format='%s%n%n%b%n%nAlso add a new file.' |
+git commit -F -
+------------

You can use the much shorter "%B" instead of "%s%n%n%b" these days, and
as a bonus, it will use the right number of newlines for a subject-only
commit.

-Peff

Jeff King [off-list ref] writes:

You can use the much shorter "%B" instead of "%s%n%n%b" these days, and
as a bonus, it will use the right number of newlines for a subject-only
commit.

... or "%s%n%+b".