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

[Jeff King <peff@peff.net>]

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