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

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