threads / patch / 24084

patchcherry-pick: Add an option to prepend a string to the commit message

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

## tl;dr

9 messages between Jun 12, 2010 and Jun 14, 2010. Diffs are folded; open one to read it.

replies: 8people: 4as markdown or json

Bobby Powers· Jun 12, 2010, 05:07 UTC · lore

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 <bobbypowers@gmail.com>
---
 Documentation/git-cherry-pick.txt |    7 +++++++
 builtin/revert.c                  |    8 +++++++-
 2 files changed, 14 insertions(+), 1 deletions(-)
Show changes to 2 files +14 −1

Documentation/git-cherry-pick.txt, builtin/revert.c

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
Jonathan Nieder· Jun 12, 2010, 05:58 UTC · re: Bobby Powers · lore

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

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:
Show 11 quoted lines
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -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(),
>  	};
This adds an option to cherry-pick and revert...
[...]
Show 10 quoted lines
> @@ -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 ");
... 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
Junio C Hamano· Jun 12, 2010, 06:18 UTC · re: Jonathan Nieder · lore

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

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 7 quoted lines
> 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.

It might be "usable in some limited context", but does not sound "reasonable" at all, sorry.

Especially since we will be getting "replay more than one commits in sequence", I would say it would make more sense to allow this kind of per-invocation (iow, command line option) commit transmonger a bit more flexibility, e.g. being a filter, or even a script that takes the original commit object name (so that it can consult git-vs-svn mapping in it if it wants to, for example).

Jeff King· Jun 12, 2010, 06:28 UTC · re: Jonathan Nieder · lore

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

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
Bobby Powers· Jun 12, 2010, 06:43 UTC · re: Jeff King · lore

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

On 06/11/2010 11:28 PM, Jeff King wrote:
Show 12 quoted lines
> 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.

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.

Show 16 quoted lines
> 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

Show 9 quoted lines
> 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
Jonathan Nieder· Jun 12, 2010, 07:18 UTC · re: Bobby Powers · lore

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

Bobby Powers wrote:
> On 06/11/2010 11:28 PM, Jeff King wrote:
Show 19 quoted lines
>> 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 <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Show changes to Documentation/git-cherry-pick.txt +11 −0
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>
Jeff King· Jun 12, 2010, 08:19 UTC · re: Jonathan Nieder · lore

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

On Sat, Jun 12, 2010 at 02:18:50AM -0500, Jonathan Nieder wrote:
Show 6 quoted lines
> 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.

Show 7 quoted lines
> +------------
> +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
Junio C Hamano· Jun 14, 2010, 05:33 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> 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".
Junio C Hamano· Jun 14, 2010, 18:03 UTC · re: Jonathan Nieder · lore

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

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 5 quoted lines
> +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 -

This is cute, I somehow doubt any sane person would prefer doing the above over running "git commit" and fixing it up with the editor for a single commit.

It is completely a different matter if the above were in a loop that munges many commits, though. But if that is the case, the example should probably illustrate that loop as well.

← back to recent threads