[PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Trevor Gross]

It is sometimes useful to do cherry picks via rebases when there is a
sequence of picks or other git operations to combine. However, there is
no interactive rebase equivalent to the cherry-pick `-x` flag, which
adds a line to the commit body indicating the original commit.

Using `exec git cherry-pick ... -x` does work, but is not as nice
because it interrupts rebase flow; after resolving a conflict, both `git
cherry-pick --continue` and `git rebase --continue` must be run.

To improve this, introduce `-x` to the pick, reword, and edit todo
rebase commands.  This uses the same logic as cherry-pick to add a
"(cherry picked from commit ...)" note to the commit body.

Of note is that rebase will fastforward wherever possible, meaning the
check for TODO_RECORD_ORIGIN doesn't get hit and the message will not
get amended. This differs from the cherry-pick logic, which will add
"cherry picked from ..." even if a rewrite isn't otherwise necessary.

Signed-off-by: Trevor Gross <tg@trevorgross.com>
---

Link to PR with the CI runs: https://github.com/git/git/pull/2194

 Documentation/git-rebase.adoc | 16 +++++++++++++
 rebase-interactive.c          |  9 +++++---
 sequencer.c                   | 19 ++++++++++++++--
 t/t3404-rebase-interactive.sh | 42 +++++++++++++++++++++++++++++++++++
 4 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc
index f6c22d1598..d8a8e2c2d6 100644
--- a/Documentation/git-rebase.adoc
+++ b/Documentation/git-rebase.adoc
@@ -978,6 +978,22 @@ pick f4593f9 four
 exec make test
 --------------------

+Similar to `git cherry-pick`, `-x` can be specified to append a "(cherry
+picked from commit …​)" line to the commit body if the the commit base
+changes. That is, the following todo list:
+
+--------------
+pick 123456 -x
+edit 654321 -x
+--------------
+
+acts the same as:
+
+---------------------------
+$ git cherry-pick -x 123456
+$ git cherry-pick -xe 654321
+---------------------------
+
 SPLITTING COMMITS
 -----------------

diff --git a/rebase-interactive.c b/rebase-interactive.c
index 809f76a87b..6a86ab5a94 100644
--- a/rebase-interactive.c
+++ b/rebase-interactive.c
@@ -47,9 +47,9 @@ void append_todo_help(int command_count,
 		      struct strbuf *buf)
 {
 	const char *msg = _("\nCommands:\n"
-"p, pick <commit> = use commit\n"
-"r, reword <commit> = use commit, but edit the commit message\n"
-"e, edit <commit> = use commit, but stop for amending\n"
+"p, pick   [ -x ] <commit> = use commit\n"
+"r, reword [ -x ] <commit> = use commit, but edit the commit message\n"
+"e, edit   [ -x ] <commit> = use commit, but stop for amending\n"
 "s, squash <commit> = use commit, but meld into previous commit\n"
 "f, fixup [-C | -c] <commit> = like \"squash\" but keep only the previous\n"
 "                   commit's log message, unless -C is used, in which case\n"
@@ -68,6 +68,9 @@ void append_todo_help(int command_count,
 "                      to this position in the new commits. The <ref> is\n"
 "                      updated at the end of the rebase\n"
 "\n"
+"With pick, reword, or edit, -x will append a line that says \"(cherry\n"
+"picked from commit <sha>)\", similar to git-cherry-pick."
+"\n"
 "These lines can be re-ordered; they are executed from top to bottom.\n");
 	unsigned edit_todo = !(shortrevisions && shortonto);

diff --git a/sequencer.c b/sequencer.c
index 57855b0066..fde09dd77d 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1884,6 +1884,7 @@ enum todo_item_flags {
 	TODO_EDIT_MERGE_MSG    = (1 << 0),
 	TODO_REPLACE_FIXUP_MSG = (1 << 1),
 	TODO_EDIT_FIXUP_MSG    = (1 << 2),
+	TODO_RECORD_ORIGIN     = (1 << 3),
 };

 static const char first_commit_msg_str[] = N_("This is the 1st commit message:");
@@ -2390,7 +2391,7 @@ static int do_pick_commit(struct repository *r,
 		if (find_commit_subject(msg.message, &p))
 			strbuf_addstr(&ctx->message, p);

-		if (opts->record_origin) {
+		if (opts->record_origin || (item->flags & TODO_RECORD_ORIGIN)) {
 			strbuf_complete_line(&ctx->message);
 			if (!has_conforming_footer(&ctx->message, NULL, 0))
 				strbuf_addch(&ctx->message, '\n');
@@ -2758,6 +2759,14 @@ static int parse_insn_line(struct repository *r, struct replay_opts *opts,
 		return error(_("missing arguments for %s"),
 			     command_to_string(item->command));

+	if (item->command == TODO_PICK || item->command == TODO_REWORD ||
+	    item->command == TODO_EDIT) {
+		if (skip_prefix(bol, "-x", &bol)) {
+			bol += strspn(bol, " \t");
+			item->flags |= TODO_RECORD_ORIGIN;
+		}
+	}
+
 	if (item->command == TODO_EXEC || item->command == TODO_LABEL ||
 	    item->command == TODO_RESET || item->command == TODO_UPDATE_REF) {
 		int ret = 0;
@@ -5524,7 +5533,7 @@ static int single_pick(struct repository *r,
 		       struct replay_opts *opts)
 {
 	int check_todo;
-	struct todo_item item;
+	struct todo_item item = { 0 };

 	item.command = opts->action == REPLAY_PICK ?
 			TODO_PICK : TODO_REVERT;
@@ -6340,6 +6349,12 @@ static void todo_list_to_strbuf(struct repository *r,
 					  short_commit_name(r, item->commit) :
 					  oid_to_hex(&item->commit->object.oid);

+			if (item->command == TODO_PICK || item->command == TODO_EDIT ||
+			    item->command == TODO_REWORD) {
+				if (item->flags & TODO_RECORD_ORIGIN)
+					strbuf_addstr(buf, " -x");
+			}
+
 			if (item->command == TODO_FIXUP) {
 				if (item->flags & TODO_EDIT_FIXUP_MSG)
 					strbuf_addstr(buf, " -c");
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 58b3bb0c27..3ff86ebaae 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -2337,6 +2337,48 @@ test_expect_success 'non-merge commands reject merge commits' '
 	test_cmp expect actual
 '

+
+test_expect_success 'rebase -i with pick -x' '
+	git checkout A &&
+	orig_j="$(git rev-parse J)" &&
+	orig_k="$(git rev-parse K)" &&
+	orig_l="$(git rev-parse L)" &&
+	cat >fake-todo <<-EOF &&
+	# No message since this is a fastforward
+	pick -x F
+	# The rest should get the "cherry picked from " message
+	pick -x J
+	reword -x K
+	edit -x L
+	EOF
+	(
+		set_replace_editor fake-todo &&
+		git rebase -i HEAD
+	) &&
+	git log --format="---%n%s%n%b" >actual &&
+	cat >expect <<-EOF &&
+	---
+	L
+	(cherry picked from commit $orig_l)
+
+	---
+	K
+	(cherry picked from commit $orig_k)
+
+	---
+	J
+	(cherry picked from commit $orig_j)
+
+	---
+	F
+
+	---
+	A
+
+	EOF
+	test_cmp expect actual
+'
+
 # This must be the last test in this file
 test_expect_success '$EDITOR and friends are unchanged' '
 	test_editor_unchanged
--
2.50.1 (Apple Git-155)

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Junio C Hamano]

Trevor Gross <tg@trevorgross.com> writes:

First, I have to say that I personally am not a huge fan of these
"cherry picked from..." messages.

Especially because I was the one who initially introduced them and
enabled it as the default behaviour, and it turned out that people
really hated to see them (and rightfully so, given that the original
commit object were often not available to them) so much that they
threw raw eggs at me until I made it disabled by default.

Oh, the raw egg part is an exaggeration, but it was a traumatic
experience for me nevertheless ;-)

Anyway, let's see what we have here.

> Of note is that rebase will fastforward wherever possible, meaning the
> check for TODO_RECORD_ORIGIN doesn't get hit and the message will not
> get amended. This differs from the cherry-pick logic, which will add
> "cherry picked from ..." even if a rewrite isn't otherwise necessary.

Why should it behave differently?  Ease of implementation, or
are there inherent design reasons behind this difference (if so that
needs to be described here).


> +Similar to `git cherry-pick`, `-x` can be specified to append a "(cherry
> +picked from commit …​)" line to the commit body if the the commit base
> +changes. That is, the following todo list:

"the the".

> +
> +--------------
> +pick 123456 -x
> +edit 654321 -x
> +--------------

You do not mean "$verb -x 123456" (where verb in (pick, edit))?

The help text seems to contradict with the above.

> diff --git a/rebase-interactive.c b/rebase-interactive.c
> index 809f76a87b..6a86ab5a94 100644
> --- a/rebase-interactive.c
> +++ b/rebase-interactive.c
> @@ -47,9 +47,9 @@ void append_todo_help(int command_count,
>  		      struct strbuf *buf)
>  {
>  	const char *msg = _("\nCommands:\n"
> +"p, pick   [ -x ] <commit> = use commit\n"
> +"r, reword [ -x ] <commit> = use commit, but edit the commit message\n"
> +"e, edit   [ -x ] <commit> = use commit, but stop for amending\n"

So presumably the documentation part needs fixing?

> @@ -2758,6 +2759,14 @@ static int parse_insn_line(struct repository *r, struct replay_opts *opts,
>  		return error(_("missing arguments for %s"),
>  			     command_to_string(item->command));
>
> +	if (item->command == TODO_PICK || item->command == TODO_REWORD ||
> +	    item->command == TODO_EDIT) {
> +		if (skip_prefix(bol, "-x", &bol)) {
> +			bol += strspn(bol, " \t");
> +			item->flags |= TODO_RECORD_ORIGIN;

  "pick -xabcdef 123456 commit title"

is parsed just like "pick -x" but somewhere downstream it would fail
to pick up the commit object name and barf, with something like
"'abcdef' is not a commit object name"?  Or worse, do we mistake it
as picking commit abcdef whose title is "123456 commit title"?

In any case, since a valid <commit> will never begin with '-', we
should be able to design/implement a much better error checking here.

> @@ -5524,7 +5533,7 @@ static int single_pick(struct repository *r,
>  		       struct replay_opts *opts)
>  {
>  	int check_todo;
> -	struct todo_item item;
> +	struct todo_item item = { 0 };

This may be a good change, but I do not think the proposed commit log
message touched upon it.  It should.  Is it a bug that we somehow were
lucky that nobody made an access to uninitialized piece of memory here?

> @@ -6340,6 +6349,12 @@ static void todo_list_to_strbuf(struct repository *r,
>  					  short_commit_name(r, item->commit) :
>  					  oid_to_hex(&item->commit->object.oid);
>
> +			if (item->command == TODO_PICK || item->command == TODO_EDIT ||
> +			    item->command == TODO_REWORD) {
> +				if (item->flags & TODO_RECORD_ORIGIN)
> +					strbuf_addstr(buf, " -x");
> +			}

Why two nested conditional, instead of

		if ((item->command == ... ||
		     item->command == ... ||
		     item->command == ...) && (item->flags & RECORD_ORIGIN))
			add " -x";

?

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Junio C Hamano]

There is another thing.

> Using `exec git cherry-pick ... -x` does work, ...

Does it really work?  I seem to recall there is a reason why "pick"
insn in the rebase todo list and "exec git cherry-pick" would not
work identically and the distinction is rather deliberate.

Rebase copies the notes attached to the original commits to the
corresponding rewritten commits.  This is because rebase is a way to
_move_ an existing (and hopefully not yet published) history on top
of some other base, with the full intention to destroy, abandon,
remove, and forget about the original history, and nobody will see
the original commits after the rebase is finished.  Copying notes,
therefore, is a sensible way to preserve the data, as these new
commits fully _replace_ the old ones.

On the other hand, cherry-pick is about _duplicating_ a parallel
history in a new context that is separate from the original, while
preserving the original history.  Since the expectation is that the
original history will be kept (and not rewritten---otherwise the
"cherry picked from ..." comment will totally be useless), and the
new commits are being created to live in their own new _context_,
notes are not carried over.

As can be seen in the mental model above, "rebase" by its nature
is what you do with the intention not to keep the original. From
that point of view, "pick -x" is a poor fit in the context, because
for the result from "cherry-pick -x" to be any useful, the original
commit you made the picked commit out of MUST be known to those who
learn the fact that this new commit was cherry-picked from that
other commit.  It goes directly opposite to what "rebase" does, in
that the point of rebase is to destroy "that other commit" and make
sure nobody will see it after rebase is done.

So...

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Matt Hunter]

On Sun Jul 5, 2026 at 2:58 PM EDT, Junio C Hamano wrote:
> Trevor Gross <tg@trevorgross.com> writes:
>> @@ -5524,7 +5533,7 @@ static int single_pick(struct repository *r,
>>  		       struct replay_opts *opts)
>>  {
>>  	int check_todo;
>> -	struct todo_item item;
>> +	struct todo_item item = { 0 };
>
> This may be a good change, but I do not think the proposed commit log
> message touched upon it.  It should.  Is it a bug that we somehow were
> lucky that nobody made an access to uninitialized piece of memory here?

On a first glance, do_pick_commit() was only referencing the 'command'
and 'commit' fields of struct todo_item.  Trevor added a reference to
item->flags which created the need to initialize it here.

However, on a second glance, there _is_ a pre-existing reference to
item->flags in do_pick_commit() as well, at line 2410 on master
(e9019fcafe00):

    if (command == TODO_REWORD)
        reword = 1;
    else if (is_fixup(command)) {
        if (update_squash_messages(r, command, commit,
                       opts, item->flags)) {
            res = -1;
            goto leave;
        }

It doesn't look like this code is actually reachable from single_pick()
as written, since it is guarded by is_fixup(command) and single_pick()
doesn't set such a command.

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Jeff King]

On Sun, Jul 05, 2026 at 02:09:06PM +0000, Trevor Gross wrote:

> It is sometimes useful to do cherry picks via rebases when there is a
> sequence of picks or other git operations to combine. However, there is
> no interactive rebase equivalent to the cherry-pick `-x` flag, which
> adds a line to the commit body indicating the original commit.
> 
> Using `exec git cherry-pick ... -x` does work, but is not as nice
> because it interrupts rebase flow; after resolving a conflict, both `git
> cherry-pick --continue` and `git rebase --continue` must be run.

To me this feels like you're approaching the problem backwards. Mostly
because rebase and cherry-pick are _kind of_ the same operation.

Usually a rebase is about rewriting the commits on a new base so that
you can throw away the old ones. And that's why git-rebase generally
rewrites the branch you're on, and replaces those old commits. So adding
a "cherry-picked from..." annotation doesn't make sense there; nobody
would have those old commits!

And so while cherry-pick is doing roughly the same thing under the hood,
it has different defaults: you specify a read-only source from which to
pick the commits (and "-x" may or may not make sense).

So I can see why you might use git-rebase to do what is essentially a
cherry-pick, porting options from cherry-pick to rebase feels weird. Why
can't we fix the problems in cherry-pick that make you want to use
rebase instead?

Once upon a time they had very different backends, but these days
they're both using the sequencer subsystem under the hood. And it sounds
like you just want to do interactive sequencer type things. If there was
an interactive cherry-pick option, would that be enough? I wonder how
far we are from that.

Let's do a little experiment that stops the cherry-pick in the middle,
like this:

  # start with a repo with any file
  git init
  echo base >file
  git add file
  git commit -m file

  # one branch makes a few commits
  git checkout -b branch-a main
  for i in a1 a2 a3; do
	echo $i >file
	git commit -am $i
  done

  # another one does the same
  git checkout -b branch-b main
  for i in b1 b2 b3; do
	echo $i >file
	git commit -am $i
  done

  # and now we try to cherry-pick all of branch-a, which will
  # fail with conflicts
  git cherry-pick main..branch-a

And now let's look in the sequencer directory:

  $ cat .git/sequencer/todo
  pick 206bede a1
  pick 638aff4 a2
  pick ec375c4 a3

So what I'm wondering specifically: have we done 99% of the work to have
interactive cherry-pick, and we just need to add a "-i" option to let
the user edit that todo file before we start executing it?

To be clear, I don't know the answer. It's been ages since I've looked
at sequencer code, so there might be more gotchas. That's just my gut
feeling from a high level after reading your message.

> To improve this, introduce `-x` to the pick, reword, and edit todo
> rebase commands.  This uses the same logic as cherry-pick to add a
> "(cherry picked from commit ...)" note to the commit body.

There is one thing that differs here from how cherry-pick works. Even
though cherry-pick is using the sequencer under the hood, it does not
allow individual "pick -x" commands, but instead records it as an option
for the whole operation. So if you add "-x" to the conflicting
cherry-pick above, you can see:

  $ cat .git/sequencer/opts
  [options]
	record-origin = true

That's less flexible, since you can't have per-pick "-x" behavior. If
that's important to you, I think it might be reasonable to support the
"-x" option for those sequencer commands, and have "cherry-pick -x" just
add it automatically to each line (rather than record the global
option).

> Of note is that rebase will fastforward wherever possible, meaning the
> check for TODO_RECORD_ORIGIN doesn't get hit and the message will not
> get amended. This differs from the cherry-pick logic, which will add
> "cherry picked from ..." even if a rewrite isn't otherwise necessary.

This sounds like another case where cherry-pick and rebase have subtly
different behaviors, even though the core functionality is still "pick
these commits". So being able to stick to the cherry-pick command for
cherry-picking may be preferable.

-Peff

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Phillip Wood]

On 06/07/2026 01:24, Jeff King wrote:
> On Sun, Jul 05, 2026 at 02:09:06PM +0000, Trevor Gross wrote:
> 
>> It is sometimes useful to do cherry picks via rebases when there is a
>> sequence of picks or other git operations to combine. However, there is
>> no interactive rebase equivalent to the cherry-pick `-x` flag, which
>> adds a line to the commit body indicating the original commit.
>>
>> Using `exec git cherry-pick ... -x` does work, but is not as nice
>> because it interrupts rebase flow; after resolving a conflict, both `git
>> cherry-pick --continue` and `git rebase --continue` must be run.
> 
> To me this feels like you're approaching the problem backwards. Mostly
> because rebase and cherry-pick are _kind of_ the same operation.
> 
> Usually a rebase is about rewriting the commits on a new base so that
> you can throw away the old ones. And that's why git-rebase generally
> rewrites the branch you're on, and replaces those old commits. So adding
> a "cherry-picked from..." annotation doesn't make sense there; nobody
> would have those old commits!

Exactly

> And so while cherry-pick is doing roughly the same thing under the hood,
> it has different defaults: you specify a read-only source from which to
> pick the commits (and "-x" may or may not make sense).
> 
> So I can see why you might use git-rebase to do what is essentially a
> cherry-pick, porting options from cherry-pick to rebase feels weird. Why
> can't we fix the problems in cherry-pick that make you want to use
> rebase instead?

I think that would be a better solution. Trevor - what is missing from 
"git cherry-pick" that means you end up using "git rebase" instead?

> So what I'm wondering specifically: have we done 99% of the work to have
> interactive cherry-pick, and we just need to add a "-i" option to let
> the user edit that todo file before we start executing it?
> 
> To be clear, I don't know the answer. It's been ages since I've looked
> at sequencer code, so there might be more gotchas. That's just my gut
> feeling from a high level after reading your message.

I don't think it would be much work. The code that edits the todo list 
is rebase specific because it deals with rebase.missingCommitsCheck but 
it shouldn't be too difficult to generalize it. I do wonder though if it 
makes sense to support all of the usual commands when cherry-picking 
especially with `-x`. In particular I'm not sure about adding support 
for `edit -x`, or for `pick -x` followed by `fixup` - what does the 
trailer mean when the commit has been edited or fixed up? (though if 
you're back-porting bug fixes I guess some degree of editing is inevitable)

On a slight tangent I've sometimes wanted to be able to do

	git cherry-pick --exec 'make test' some commits

>> To improve this, introduce `-x` to the pick, reword, and edit todo
>> rebase commands.  This uses the same logic as cherry-pick to add a
>> "(cherry picked from commit ...)" note to the commit body.
> 
> There is one thing that differs here from how cherry-pick works. Even
> though cherry-pick is using the sequencer under the hood, it does not
> allow individual "pick -x" commands, but instead records it as an option
> for the whole operation. So if you add "-x" to the conflicting
> cherry-pick above, you can see:
> 
>    $ cat .git/sequencer/opts
>    [options]
> 	record-origin = true
> 
> That's less flexible, since you can't have per-pick "-x" behavior. If
> that's important to you, I think it might be reasonable to support the
> "-x" option for those sequencer commands, and have "cherry-pick -x" just
> add it automatically to each line (rather than record the global
> option).

Yes, if we're adding a per-commit flag to record the origin it would be 
much nicer just to set that flag when we build the todo list rather than 
having to do

	if (opt->record_origin || (item->flags &  TODO_RECORD_ORIGIN))

to see whether we need to add the trailer.

>> Of note is that rebase will fastforward wherever possible, meaning the
>> check for TODO_RECORD_ORIGIN doesn't get hit and the message will not
>> get amended. This differs from the cherry-pick logic, which will add
>> "cherry picked from ..." even if a rewrite isn't otherwise necessary.
> 
> This sounds like another case where cherry-pick and rebase have subtly
> different behaviors, even though the core functionality is still "pick
> these commits". So being able to stick to the cherry-pick command for
> cherry-picking may be preferable.

I think that is a consequence of the way this patch is implemented - it 
adds the new per-commit flag but does not change the conditions for 
preventing a fast-forward in do_pick_commit() or skip_unnecessary_picks().

Thanks

Phillip

Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

>> Usually a rebase is about rewriting the commits on a new base so that
>> you can throw away the old ones. And that's why git-rebase generally
>> rewrites the branch you're on, and replaces those old commits. So adding
>> a "cherry-picked from..." annotation doesn't make sense there; nobody
>> would have those old commits!
>
> Exactly

;-)  

Whew.  Briefly I wondered if I were the only one who felt 'rebase'
and 'cherry-pick' serve two different purposes and need to behave
differently, e.g., with respect to how notes on old commits are
dealt with.

> On a slight tangent I've sometimes wanted to be able to do
>
> 	git cherry-pick --exec 'make test' some commits

Yes, I agree that is something quite handy.

Thanks.