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

From: Jeff King <peff@peff.net>
Date: Jul 7, 2026, 04:27 UTC
Message-ID: <20260707042712.GA677056@coredump.intra.peff.net>
In-Reply-To: <5d238e0d-18ba-429a-a9a4-a3988b00e1e1@gmail.com>

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

Show 12 quoted lines

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