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

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: dmitry <at> gutov.dev, eliz <at> gnu.org, sbaugh <at> janestreet.com,
 79408 <at> debbugs.gnu.org
Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking
Date: Thu, 11 Sep 2025 09:55:37 +0300

>> We could also try to use the same UI as in e.g. Dired:
>>
>> - in a *vc-change-log* buffer use 'm' to mark revisions;
>
> Right, this is what I was thinking already.
>
>> - type 'C' to copy or 'M' to move (actually 'R' in Dired);
>
> Yes, let's use 'C' to cherry-pick.  Currently I'm not planning something
> for moving revisions between branches, but we could use 'R' for that if
> we decide to add it later.
>
>> - select a branch name in the minibuffer with completion.
>
> 'git cherry-pick' and 'hg graft' work only for applying commits onto a
> branch that's currently checked out.  So we would have to implement our
> own complex thing, for each backend, if we wanted to be able to
> cherry-pick onto arbitrary branches.  I'm also not sure how useful it
> would be to be able to do that, to be honest.

Agreed, no need to use exactly the same analogy as copying files in Dired.

> On the other hand, if there are other working trees, prompting which
> working tree to cherry-pick onto could be implemented in generic code
> and would be an alternative to using C-x v w w to switch the working
> directory or invoke C-x v b l from the other working tree.  So I'll
> implement that.  C RET will always mean to cherry-pick to the current
> working tree's branch.

I guess this means two commands: one generic command that reads
a branch name and a commit, and another command specific to log-view
that uses the marked commits without prompting.

Previous Next

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