Package: emacs;
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Mon, 8 Sep 2025 11:28:02 UTC
Severity: normal
Found in version 31.0.50
View this message in rfc822 format
From: Spencer Baugh <sbaugh <at> janestreet.com> To: Sean Whitton <spwhitton <at> spwhitton.name> Cc: dmitry <at> gutov.dev, eliz <at> gnu.org, juri <at> linkov.net, 79408 <at> debbugs.gnu.org Subject: bug#79408: 31.0.50; VC commands for cherry-picking Date: Thu, 11 Sep 2025 14:14:52 -0400
Sean Whitton <spwhitton <at> spwhitton.name> writes: > Hello, > > On Tue 09 Sep 2025 at 11:07am -04, Spencer Baugh wrote: > >> No. It would be format-patch followed by either apply-patch or >> checkin-patch. >> >> format-patch would be "git format-patch" >> apply-patch would be "git apply" >> (a new version of) checkin-patch would be "git am" >> [...] >> The VCS would still be (basically) handling the whole thing. I'm >> suggesting that we basically just run: >> >> git format-patch | git am >> >> or: >> >> hg import | hg export >> >> Which (I think) is how cherry-picking works under the hood historically >> in git anyway. > > Ah, got it. Nice! I think this is a better API indeed. > > (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.) That would be nice indeed. >> Maybe we could prompt with Log Edit for each commit, even when >> cherry-picking multiple commits? I guess that would make cherry-picking >> multiple commits quite annoying... >> >> Oh, what if before opening any Log Edit buffers, we prompt the user >> whether they want to edit the commit messages for the commits being >> cherry-picked? We could give them several options: >> >> - don't manually edit messages but add cherry-pick message to each of them >> - don't manually edit messages and don't add cherry-pick message >> - manually edit all the messages >> >> This would give the user the ability to choose to edit commit messages >> even when cherry-picking multiple commits, which might be nice. >> >> Or... an even more radical idea would be to let them pick and choose >> which commit messages they want to edit, and even allow them to stop and >> edit individual commits in a series. Similar to git rebase -i. >> >> Actually, don't we need to be able to stop in the middle of >> cherry-picking a series of commits anyway, since we need to be able to >> resolve conflicts? I think that implies a substantially more rich UI >> then we've been talking about so far... > > I've been thinking that if there are conflicts we go into a merge > conflict state for the failed cherry-pick, and abandon all subsequent > cherry-picks. After the user has resolved that conflict they can > execute another cherry-pick operation to grab the remaining commits. > (We could unmark the commits that were successfully cherry-picked.) > > That means we can implement a useful multiple cherry-pick without > blocking on doing a large amount of new UI design, and indeed UI > implementation, up front. Reasonable. Though I feel like "don't support multiple cherry-pick in the first version" is becoming more attractive, since even single cherry-pick will be very useful, and avoids having to deal with these issues now. > 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. True, it is clunky. 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. > 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. > > I guess we would want some sort of major mode that could separate the > buffer into portions? Or do we want custom.el-style text fields? WDYT? Interesting idea. That same kind of UI could also be useful for interactive rebase, I guess. Personally I think custom.el-style text fields are also pretty clumsy, so I'd avoid those. >> What about mentioning tip in the name? For example: >> >> - vc-delete-tip-revisions >> - vc-strip-tip-revisions >> - vc-reset-tip-revisions >> >> Or maybe just vc-reset-revisions on its own would work as a name? "git >> reset" already only operates on tip, so there's prior art. >> >> I guess if we're going with the "vc-revision-cherry-pick" scheme, we >> might want to match that convention, with e.g. "vc-revision-reset". > > I would like to see if we can avoid "reset" because even in Git it means > several different things (most fundamentally, clearing the staging area, > which isn't a thing we recognise in VC anyway). Good point, that's a strong reason to avoid reset. > I think "strip" is the right verb to use. Also it kind of implies that > you can only strip from the end of the branch, to me, at least. Yes, I like "strip". > 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. Oh right. Ugh. That is indeed a pretty good reason not to use "tip". > In the recent new Info nodes I wrote I talked about the "end" of the > branch, so I would suggest one of these: > > - 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?
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.