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

Previous Next

Full log

Message #50 received at 79408 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, Spencer Baugh <sbaugh <at> janestreet.com>, eliz <at> gnu.org,
 79408 <at> debbugs.gnu.org
Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking
Date: Fri, 12 Sep 2025 10:57:33 +0100

Hello,

On Thu 11 Sep 2025 at 08:18pm +03, Juri Linkov wrote:

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

Yes, exactly.

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

To my mind, this still has the undesirable properties of Git's own
repeated invocations of EDITOR, but it could work.

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

I like this name a lot.  On the other hand, I think 'strip' is a bit
more informative than 'pop', because 'pop' implies you get the revision
back in your hand in some way, instead of just discarding it.

-- 
Sean Whitton

Previous Next

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