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

[Jeff King <peff@peff.net>]

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

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

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

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

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