Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking

From: Sean Whitton <[email-masked]>
Date: Fri, 12 Sep 2025 13:55:07 +0100

Hello,

On Thu 11 Sep 2025 at 02:14pm -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Though I guess... one could imagine supporting
> log-view-modify-change-comment via clever use of git rebase.  Maybe that
> would make it easy enough to modify old messages that it wouldn't
> matter?
>
> Or maybe that's even easy enough that editing the commit message isn't
> necessary in the first place.

It's already supported for Git, actually, on master.

You make an interesting point.  At the end of a multiple commit
cherry-pick, we could display a non-shortlog Log View buffer with just
the result of the cherry-pick, and display a message saying "You can use
\\[log-view-modify-change-comment] to modify any of these messages".
That might be perfectly adequate and also means that when you don't need
to make any edits, you're already done.

> Interesting idea.  That same kind of UI could also be useful for
> interactive rebase, I guess.

Potentially, though I think full interactive rebases are probably
out-of-scope for VC because they're highly VCS-specific.

> Personally I think custom.el-style text fields are also pretty clumsy,
> so I'd avoid those.

Yeah, especially when one is used to a full Log Edit buffer for editing
commit messages most of the time.

>> - vc-strip-revisions
>> - vc-strip-end-revisions
>> - vc-strip-branch-end-revisions
>> - vc-strip-revisions-at-end
>> - vc-strip-revisions-from-end
>>
>> I think I like vc-strip-revisions-from-end most.
>
> Agreed, I like vc-strip-revisions-from-end best also.
>
> Though maybe vc-revisions-strip-from-end is better, if we're going with
> vc-revisions-cherry-pick and vc-revisions-revert?  Or vc-revision-*
> (singular "revision" instead of plural "revisions") for all of those?

Yes, I agree, vc-revision- for all of them.

-- 
Sean Whitton