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(-)

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.

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).

"the the".

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

The help text seems to contradict with the above.

So presumably the documentation part needs fixing?

  "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.

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?

Why two nested conditional, instead of

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

?

There is another thing.

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...

On Sun Jul 5, 2026 at 2:58 PM EDT, Junio C Hamano wrote:

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.

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

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.

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).

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

On 06/07/2026 01:24, Jeff King wrote:

Exactly

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?

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

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.

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

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

;-)  

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.

Yes, I agree that is something quite handy.

Thanks.

On Mon, Jul 06, 2026 at 11:08:18AM +0100, Phillip Wood wrote:

I'd probably err on the side of assuming the user knows what they're doing, and will mention any edits in the commit message as appropriate. Maybe that's being too optimistic. :)

Yeah, though in that case I'd usually cherry-pick and then just do an in-place "rebase -x 'make test'". You could really do _almost_ any cherry-pick sequencer operation like that, which is perhaps why we haven't see a huge number of requests for it.

This "-x" thing is special because it's inherently about looking at the original commit id, as opposed to fiddling with our rebased version. But I guess you could "cherry-pick -x" and then rebase (doing whatever rearranging and markup you wanted) the result.

-Peff