GNU bug report logs - #79408
31.0.50; VC commands for cherry-picking

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, eliz <at> gnu.org, 79408 <at> debbugs.gnu.org, dmitry <at> gutov.dev
Subject: bug#79408: 31.0.50; VC commands for cherry-picking
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.