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

From: Juri Linkov <[email-masked]>
Date: Thu, 11 Sep 2025 20:18:44 +0300

> (It would also allow me to reimplement some other useful things from
> mailscripts.el in VC, such as applying patches attached to an e-mail, if
> we assume those are in a VCS-specific format, as they tend to be these
> days.)

Such command would be nice to have.  Currently applying a patch is
quite cumbersome, e.g. need to select a region on the patch, then invoke

  M-| (M-x shell-command-on-region) cd ~/src/emacs/...; git apply RET

> But yeah, certainly, the eventual desiderata would be for some way to
> edit commit messages for multiple commits.  Regarding invoking Log Edit
> multiple times, that's natural to us as experienced Git users, for sure,
> and I thought about it too.  It's fairly clunky though -- for example,
> there isn't a natural way to go back a few steps a edit a previous
> message again -- and I wonder if we can come up with something nicer.

It's possible to create multiple buffers with unique names like
*vc-log*<2>, *vc-log*<3>, ...  After 'C-c C-c' in one buffer
the next buffer appears in the same window automatically
when the previous buffer goes away.

> ISTM that a single buffer in which all the commit messages were
> available to edit, somehow, would be more useful, and also minimise UI
> confusion, because it would be just like our existing commit UI for VC
> where there is a single *vc-log* buffer and then the operation is
> atomic.

The current *vc-log* buffer is modeled after a mail message buffer
with multiple header fields.  So a single multi-commit buffer
would be as heavy as having a multi-message mails buffer.

> I'm a bit hesitant about "tip" because it actually appears in the VC UI
> with Mercurial, but doesn't always mean the commit that's checked out,
> and from which we would strip.  For example if you fetch without
> updating your working tree, the tip label will be beyond what you have
> and can delete commits from.

Then maybe 'vc-pop-revision' like from the top of the stack.