From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 08 07:27:35 2025 Received: (at submit) by debbugs.gnu.org; 8 Sep 2025 11:27:35 +0000 Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uva22-0000ly-Lu for submit@debbugs.gnu.org; Mon, 08 Sep 2025 07:27:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:40384) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uva1v-0000lK-4J for submit@debbugs.gnu.org; Mon, 08 Sep 2025 07:27:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uva1o-00063e-Qr for bug-gnu-emacs@gnu.org; Mon, 08 Sep 2025 07:27:21 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uva1h-00046i-I5 for bug-gnu-emacs@gnu.org; Mon, 08 Sep 2025 07:27:20 -0400 DKIM-Signature: a=rsa-sha256; b=GZrBM2W8g026HA1lEFcDDrmGfFlH/DF2es2AsJoBzlWABieAHRIfn7wcwrrRZ+nNc2BJgI9qh9Afl7kx9yDzkYFOXSo+U90xKqntog1gk+29tvOrPNWDCCdAUN8gQxlFKHwWf4G9c7Z7SRv5QrJ906f8hIZs/LtU4TXStMQyGUxj5fdlfE3f3mADRIsl6c7V1q3nfA6q28bSUAhDvbbcqDcdsHOZ/w99dGxRz9OKPWMD9XLyuvYmKXpgMeoSr49dYjt2v3aILcQPGDcoD2fyScBRXaAHYfek5H1wiq7qmgUtVh18UA1N+UD4dp6jzxjilvRt/mcJmIpZ55qrvEZaiA==; s=purelymail2; d=spwhitton.name; v=1; bh=rQNeZI07NmJAvyKmKa0tJqYJv10FNoRioCzS4ZCMxm0=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=KLokBcKvOYgogF5rTBMbGg6J1dTmHmsmMiRjQPdJn2G92DcgTxSxuoA8mS9BkJJI0ttcxfMM6+C2yd9YUdnwphriBjOxume1DBylxniHEElvh+eHsA2knPFp20estK2D7gjMrGPoEpFJYnR6uSkK2sCLhO2a51DGIgc7J+o/GGI1JANEv7UhT3F8n3Iy/ii53aEkSg0pGIZyO5Kpej2TQ4yJh8vm0tQ3vKfQMmNYGHN0PkEVuaMwu2zjkkr1fZ/HxOokZeCuFGFVixb35fqt/XzQGE28Rxk5MfEcW1a508mmnlD6Qzc54YAGAXmuLGFiXeGnqJgXMntAkTvlI+qWMw==; s=purelymail2; d=purelymail.com; v=1; bh=rQNeZI07NmJAvyKmKa0tJqYJv10FNoRioCzS4ZCMxm0=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: bug-gnu-emacs@gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -983027225 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 08 Sep 2025 11:27:03 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 8DB83940466; Mon, 08 Sep 2025 12:27:02 +0100 (BST) From: Sean Whitton To: bug-gnu-emacs@gnu.org Subject: 31.0.50; VC commands for cherry-picking Date: Mon, 08 Sep 2025 12:27:02 +0100 Message-ID: <87a535mbg9.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=34.202.193.197; envelope-from=spwhitton@spwhitton.name; helo=sendmail.purelymail.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) X-debbugs-cc: eliz@gnu.org, sbaugh@janestreet.com, dmitry@gutov.dev, juri@linkov.net Hello, I'd like to add VC commands to cherry-pick changes. These are my proposed additions to the VC API: ;; - cherry-pick (files comment rev reverse) ;; ;; Copy a REV's changes, log message, author and author timestamp as a ;; new commit on the current branch. If REVERSE, reverse REV's changes. ;; FILES is for forward-compatibility; existing implementations aren't ;; able to limit the changes copied from REV to those made to FILES. ;; ;; - cherry-apply (files rev reverse) ;; ;; Copy REV's changes to FILES to this working directory. If REVERSE, ;; reverse REV's changes. (When REVERSE is nil, typically REV will be ;; a revision from another branch.) ;; ;; - cherry-pick-comment (files rev reverse) ;; ;; Return a string to be appended to the log message when ;; cherry-picking REV onto another branch. This is Git's "(cherry ;; picked from commit ...)" and Mercurial's "(grafted from ...)", ;; or if REVERSE, Git's "This reverts commit ...". ;; FILES is for forward-compatibility; existing implementations care ;; only about REV. These are my proposed commands: vc-cherry-pick: - Gets the log message for REV with get-change-comment API function. - Gets the string to append with cherry-pick-comment API function. - Puts these together, starts a Log Edit session for the user to amend the message (e.g. for Git, doing C-c C-s to add a sign-off). - On C-c C-c, calls the cherry-pick API function for the backend to do the cherry-pick. Examples: vc-git-cherry-pick would invoke 'git cherry-pick' or 'git revert' depending on whether REVERT. vc-hg-cherry-pick would invoke 'hg graft' or 'hg backout'. Will have vc-checkin's COMMENT, INITIAL-CONTENTS arguments so calling from Lisp can skip the Log Edit session. A prefix argument might toggle whether to append the cherry-pick comment. We'll be expecting the user to invoke this from Log View mode. If multiple commits are marked, then I think we have to skip the Log Edit session, for now, because we don't have a nice way to prompt for multiple messages. vc-undo-revision (vc-revert is taken): Same as vc-cherry-pick, except passes REVERSE non-nil at the appropriate points. No prefix argument. vc-cherry-apply: The advantage of having a backend API function for this is that the backend can use its full merging logic. A generic vc-default-cherry-apply can be implementated similarly to vc-apply-to-other-working-tree. vc-undo-apply: Like vc-cherry-apply except passes REVERSE non-nil at the appropriate point. Similarly there can be a vc-default-reverse-cherry-apply. I think this is a good way to divide up the functionality on the frontend, but I'm open to suggestions. Thanks! -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 08 14:40:45 2025 Received: (at 79408) by debbugs.gnu.org; 8 Sep 2025 18:40:45 +0000 Received: from localhost ([127.0.0.1]:52551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvgnE-0008UO-K5 for submit@debbugs.gnu.org; Mon, 08 Sep 2025 14:40:44 -0400 Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]:43180) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvgn9-0008Tf-Bo for 79408@debbugs.gnu.org; Mon, 08 Sep 2025 14:40:40 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4cLG3d37K5z9stK; Mon, 8 Sep 2025 20:40:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757356829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dFiIA5tqGn3CcTdmjvcPvaQ5gAEsTRMQPRkKCpPTUXA=; b=r3EtGoSJ/mHy85IFUvj2azw7sk5BgMBRj7/xsHLC8CoQqvwbx4qLOLVERNauyx04r36VNg KsODaU+8kZQ3fYUcIId+BCiCZL7qz/q/jp8WZHYu81D5xxZ4Tb2Ul22lEq6dOHcNEaFmTO Bm1lzqWKYcK7AqtJ4KUIlxm6HH9+yTwUEuWEJLM5Tnh53Wyhy/+YeIUnqNzZULu0yaKbm5 GamuiArR281XErgVuT4qNELqpPGSg5R2902/imvDCMDuPkGxLP7eIO+SzabOwKSbVtdj59 IbZmTZAjBoMR/eKFDb+NYPAtCVDiLozDGCT/i/WYL1qqWnE2b9hnJ3ECudeCdg== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::102 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87a535mbg9.fsf@zephyr.silentflame.com> Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> Date: Mon, 08 Sep 2025 21:34:19 +0300 Message-ID: <877by8kd3o.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cLG3d37K5z9stK X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, sbaugh@janestreet.com, eliz@gnu.org, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > These are my proposed commands: > > vc-cherry-pick: > - Gets the log message for REV with get-change-comment API function. > - Gets the string to append with cherry-pick-comment API function. > - Puts these together, starts a Log Edit session for the user to amend > the message (e.g. for Git, doing C-c C-s to add a sign-off). Will 'C-c C-d' be supported to show diff from the Log Edit buffer? > We'll be expecting the user to invoke this from Log View mode. I guess the basic workflow would be to view a branch log with e.g. 'C-x v b l', then after marking the required commits invoke the new commands. > If multiple commits are marked, then I think we have to skip the Log Edit > session, for now, because we don't have a nice way to prompt for > multiple messages. Maybe even for the single commit 'vc-cherry-pick' could ask for confirmation (maybe with a multiple choice), and optionally commit straight away without showing a Log Edit buffer. > vc-cherry-apply: > The advantage of having a backend API function for this is that the > backend can use its full merging logic. > A generic vc-default-cherry-apply can be implementated similarly to > vc-apply-to-other-working-tree. > > vc-undo-apply: > Like vc-cherry-apply except passes REVERSE non-nil at the appropriate > point. Similarly there can be a vc-default-reverse-cherry-apply. Are the last two commands equivalent to showing diff and invoking 'C-c RET a' on it, with or without the prefix argument REVERSE? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 08 14:56:48 2025 Received: (at 79408) by debbugs.gnu.org; 8 Sep 2025 18:56:48 +0000 Received: from localhost ([127.0.0.1]:52601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvh2k-0002Gz-MP for submit@debbugs.gnu.org; Mon, 08 Sep 2025 14:56:47 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:51049) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvh2f-0002FZ-Dn for 79408@debbugs.gnu.org; Mon, 08 Sep 2025 14:56:43 -0400 From: Spencer Baugh To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87a535mbg9.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Mon, 08 Sep 2025 12:27:02 +0100") References: <87a535mbg9.fsf@zephyr.silentflame.com> Date: Mon, 08 Sep 2025 14:56:34 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757357794; bh=vtlWisbL28zwHdhLynBZf1cUc+urc5gZLM4dJ6fhmh0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=xWM3PbJ9xmQ1Mx1y4fNaN3xI0o/kyDqz4FI7s/ktCxypjpOAoP1YBEt5bWja9T2W+ Vieb1BP6m3VBODjYdIwPbrvlRE8scJcx3Qirxj7siM0MLTIbhMPVoG5OBbhvmG74JH KmYgiOBdE6bkI55dmP4grodYgiU8jBjul87vUy2X9eki1Ai3lbvC53vy1Mcy0NgMHs AHTCNz+2Y1VhrfCIZlvo6tM7X49EFn20NyacSt6zXcD6P6r9E1klLhLjkX78KiZgVo +hR0nDeuckuDEsNbd40B1tssgMTB/YqpWsITVuaWCV1kURfoSGvngT0rRpHTCgXeEE VthugtYPSNncw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, juri@linkov.net, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Sean Whitton writes: > X-debbugs-cc: eliz@gnu.org, sbaugh@janestreet.com, dmitry@gutov.dev, juri@linkov.net > > Hello, > > I'd like to add VC commands to cherry-pick changes. Exciting! > These are my proposed additions to the VC API: > > ;; - cherry-pick (files comment rev reverse) > ;; > ;; Copy a REV's changes, log message, author and author timestamp as a > ;; new commit on the current branch. If REVERSE, reverse REV's changes. > ;; FILES is for forward-compatibility; existing implementations aren't > ;; able to limit the changes copied from REV to those made to FILES. > > ;; - cherry-apply (files rev reverse) > ;; > ;; Copy REV's changes to FILES to this working directory. If REVERSE, > ;; reverse REV's changes. (When REVERSE is nil, typically REV will be > ;; a revision from another branch.) This reminded me of how we don't have a way to do format-patch using vc; that's somewhat related, and would be nice to support. In fact, I wonder if perhaps: - a new format-patch backend function - a new apply-patch backend function (to take advantage of better backend-specific merging) - maybe a fancier checkin-patch backend function Could replace the need for these specialized backend functions? (I think git-cherry-pick used to be implemented as format-patch + apply under the hood, years ago) > ;; - cherry-pick-comment (files rev reverse) > ;; > ;; Return a string to be appended to the log message when > ;; cherry-picking REV onto another branch. This is Git's "(cherry > ;; picked from commit ...)" and Mercurial's "(grafted from ...)", > ;; or if REVERSE, Git's "This reverts commit ...". > ;; FILES is for forward-compatibility; existing implementations care > ;; only about REV. > > These are my proposed commands: > > vc-cherry-pick: > - Gets the log message for REV with get-change-comment API function. > - Gets the string to append with cherry-pick-comment API function. > - Puts these together, starts a Log Edit session for the user to amend > the message (e.g. for Git, doing C-c C-s to add a sign-off). > - On C-c C-c, calls the cherry-pick API function for the backend to do > the cherry-pick. > Examples: vc-git-cherry-pick would invoke 'git cherry-pick' or > 'git revert' depending on whether REVERT. > vc-hg-cherry-pick would invoke 'hg graft' or 'hg backout'. > > Will have vc-checkin's COMMENT, INITIAL-CONTENTS arguments so calling > from Lisp can skip the Log Edit session. > > A prefix argument might toggle whether to append the cherry-pick > comment. That sounds like a bit of a waste of the prefix argument, since the user could always just delete that comment. I think we'd be better off just not having the prefix argument do anything for now, and maybe we'll find a better use in the future. > We'll be expecting the user to invoke this from Log View mode. If > multiple commits are marked, then I think we have to skip the Log Edit > session, for now, because we don't have a nice way to prompt for > multiple messages. This sounds reasonable. I personally rarely care about editing the commit message, but it's not hard for me to just hit C-c C-c. > vc-undo-revision (vc-revert is taken): > Same as vc-cherry-pick, except passes REVERSE non-nil at the > appropriate points. No prefix argument. Maybe we could name it vc-revert-revision? Actually maybe we should name the commands something like: vc-revision-cherry-pick vc-revision-cherry-pick-apply vc-revision-revert vc-revision-revert-apply To display more directly how they're closely related and symmetric. > vc-cherry-apply: > The advantage of having a backend API function for this is that the > backend can use its full merging logic. > A generic vc-default-cherry-apply can be implementated similarly to > vc-apply-to-other-working-tree. Right. I assume that generic implementation would use the 'diff backend function. And the sole disadvantage of such a generic implementation is that it would have less smart merging. I wonder, could we enhance diff-mode's ability to do conflict resolution? Maybe it can talk to vc for this, maybe using an apply-patch backend function like I suggested above? > vc-undo-apply: > Like vc-cherry-apply except passes REVERSE non-nil at the appropriate > point. Similarly there can be a vc-default-reverse-cherry-apply. That sounds good, but... I wonder if we even need to support vc-cherry-apply and vc-undo-apply? At least right now. Two very different reasons why we might not want those: - Those seem primarily useful when you want to actually edit the diff before committing. But, it seems to me that using diff-mode for such an operation is already pretty natural, and should be encouraged. The way I do those two operations today in hg is: - Open up vc-print-log starting at some revision - Find the revision I want to revert or cherry-apply - Hit d or D to open up the diff - Use diff-mode to do the editing Perhaps that is sufficient? - In a completely different direction: what if we only supported cherry-pick, but also added support for git reset --soft? In git, I often do cherry-apply by just cherry-picking and then resetting. This is a bit weird, but it might save us some complexity if we want to support git reset --soft anyway? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 05:57:31 2025 Received: (at 79408) by debbugs.gnu.org; 9 Sep 2025 09:57:31 +0000 Received: from localhost ([127.0.0.1]:57753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvv6Q-0008QB-HA for submit@debbugs.gnu.org; Tue, 09 Sep 2025 05:57:31 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:48220) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvv6L-0008Pa-K7 for 79408@debbugs.gnu.org; Tue, 09 Sep 2025 05:57:26 -0400 DKIM-Signature: a=rsa-sha256; b=RKmXOMgV87F1+WNiyQiOkDI4RhZgHUofTHNR4N0QfZB4Tsd/uCtpGgpfsj3y8ddrTZFEWBhTlZyZhO3xUNZq3ef1t9LQCueKnZDuAMpCAI337+d4k3GgCvjuAvRcLEP3hE70yaZQ+tBdkv/NT3IVCSB8Vlr5zxXysYwArpWCGsEcAoWUP2bOkdHyHxfFr/Az82PkXxKHC5nuz7VCf9vEJXzd+j2gha83OrjTfO2LvQE7yMwYqQgGd9FbO4lw73tbWzOjjUVa9jLsunOYw5lCShIp3RrHMplZRlmq/BILrJHegaBqlElOFz+n6yyoczk/4npgILH5vdSslp3zaMNALQ==; s=purelymail2; d=spwhitton.name; v=1; bh=BlWw/anduKuNZtM05++aW68Ktnor9hiVcxctLpNzN2E=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=mcn3qG3qOZfYo6HJ5TngQuf2dmpI45Y1xuKgzoqBwHX6fhQY4a6Rp33TaeuxKsOHMEIuj+LHYjC9iDSFtcDobMM/5YTEy359D4qLXx2M+8cXH84JY5nPrCW+DwzB+8u4WFSIlGv3oJg+LxtQimCfgC/dFLuhv8V2lyRCG1nxyYmhKJzwGchIzNu7CFqDc+/Z4kh6bIwjsKM9gFJi5eo9Xcvp85nnBwvkm9XcT9W1FJ5xb802xhb7Q1LgOgm1L4Qxr/8qduRyHFmH3q84o0vRlaepKy2khbsvDDOJD65x9dVOieEU0Ah/Ju1ovoAJpxbvHgY8dYzddGke1CZyVFQR2A==; s=purelymail2; d=purelymail.com; v=1; bh=BlWw/anduKuNZtM05++aW68Ktnor9hiVcxctLpNzN2E=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -23636003; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 09 Sep 2025 09:57:17 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 85043940F55; Tue, 09 Sep 2025 10:57:16 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <877by8kd3o.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <877by8kd3o.fsf@mail.linkov.net> Date: Tue, 09 Sep 2025 10:57:16 +0100 Message-ID: <87ikhskkxv.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Mon 08 Sep 2025 at 09:34pm +03, Juri Linkov wrote: >> These are my proposed commands: >> >> vc-cherry-pick: >> - Gets the log message for REV with get-change-comment API function. >> - Gets the string to append with cherry-pick-comment API function. >> - Puts these together, starts a Log Edit session for the user to amend >> the message (e.g. for Git, doing C-c C-s to add a sign-off). > > Will 'C-c C-d' be supported to show diff from the Log Edit buffer? Yes, it should be no problem to support that. >> We'll be expecting the user to invoke this from Log View mode. > > I guess the basic workflow would be to view a branch log > with e.g. 'C-x v b l', then after marking the required commits > invoke the new commands. Right. >> If multiple commits are marked, then I think we have to skip the Log Edit >> session, for now, because we don't have a nice way to prompt for >> multiple messages. > > Maybe even for the single commit 'vc-cherry-pick' could ask > for confirmation (maybe with a multiple choice), and optionally > commit straight away without showing a Log Edit buffer. I would say that is a bit complex, because just typing C-c C-c immediately is not a lot of effort. >> vc-cherry-apply: >> The advantage of having a backend API function for this is that the >> backend can use its full merging logic. >> A generic vc-default-cherry-apply can be implementated similarly to >> vc-apply-to-other-working-tree. >> >> vc-undo-apply: >> Like vc-cherry-apply except passes REVERSE non-nil at the appropriate >> point. Similarly there can be a vc-default-reverse-cherry-apply. > > Are the last two commands equivalent to showing diff and invoking > 'C-c RET a' on it, with or without the prefix argument REVERSE? Yes, except that using 'C-c RET a' uses Emacs's merging logic, which may be less sophisticated than the backend's. Hmm. Maybe I should skip those commands for now. What do you think? -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 07:08:51 2025 Received: (at 79408) by debbugs.gnu.org; 9 Sep 2025 11:08:51 +0000 Received: from localhost ([127.0.0.1]:58114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvwDS-0004mU-Sm for submit@debbugs.gnu.org; Tue, 09 Sep 2025 07:08:51 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:42032) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvwDP-0004mC-Gj for 79408@debbugs.gnu.org; Tue, 09 Sep 2025 07:08:49 -0400 DKIM-Signature: a=rsa-sha256; b=XXKea8kZYMLsyhVdJ6nYts/K2L5EWzM2OW1wmN3Uqppa4pUakTFaCrGW6VelynEXtW7t10v/JkJVy6O+XRCdwSRCPkfJVp7GsisuVr6aNieJu0y2ugB8jal6bKoEPm7G/xKkgIEAYnJqP1ZhJiVhNFAHFZNxluMi3xWP/pgJagfglwcuD00P3X0TrcKGhAX9KkhoOYe0cd/DrWiiAM82YfzsFD7CUW2TDpYAgvBh3dlvCvsooEf9BITZnGa3N9XvS4NZ3iyVqxsb/IfIGYYEqjxWZ/3RVTXY9ilZUyHp9l3eaLFDFK2HHMUdjtIjn8VqR/FXbiqJREIpTpnMlPdwmQ==; s=purelymail2; d=spwhitton.name; v=1; bh=qZjQag/SnZ6G6JneUJfykgsMgi9Mkzv1nCd4aTEE4GQ=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=buuYqeGOyvNCD3gzsPj5/JskZeifILAU5R0WczvsSAkaocm2JrON5HXfrOgMdaMrFb5wiNf9hB1WadSwJvSg0jtuJO8pagX7Oq/nfuW9BmpARRl1iY1Mnfc7zkYktgWpARqllVh20ShrdgtnyB9ZGWbgacfOjYSsZ8eWZuZWdEtOhO+MNZX/E/8zTttmecg4X1F+Qs2CnZNo8+HqWOwt3xifhiHhhctVdFKBSAv/20gGOYmMQESl+WTUOech+56Un08dYmoYKofSd2cXXKMJpDURPmH9Tv2JmRQlmRgm0C0WTKOKQp+AaqvG2dLg+5bs0Ibd042bokYCsBUst3KXgg==; s=purelymail2; d=purelymail.com; v=1; bh=qZjQag/SnZ6G6JneUJfykgsMgi9Mkzv1nCd4aTEE4GQ=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -536878099; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 09 Sep 2025 11:08:40 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 2A813940F55; Tue, 09 Sep 2025 12:08:40 +0100 (BST) From: Sean Whitton To: Spencer Baugh Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: References: <87a535mbg9.fsf@zephyr.silentflame.com> Date: Tue, 09 Sep 2025 12:08:40 +0100 Message-ID: <87bjnjlw7b.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Mon 08 Sep 2025 at 02:56pm -04, Spencer Baugh wrote: > This reminded me of how we don't have a way to do format-patch using vc; > that's somewhat related, and would be nice to support. We do! 'M-x vc-prepare-patch' is the interactive entry point. > In fact, I wonder if perhaps: > > - a new format-patch backend function > > - a new apply-patch backend function (to take advantage of better > backend-specific merging) > > - maybe a fancier checkin-patch backend function > > Could replace the need for these specialized backend functions? > > (I think git-cherry-pick used to be implemented as format-patch + apply > under the hood, years ago) So, the generic code would be responsible for invoking format-patch, then apply-patch, then checkin-patch, in that order, right? A couple of tricky things: - We would need a way to extract authorship information and then pass that into the improved checkin-patch. An author's name and e-mail address is generic enough, but the representation of dates might be something highly backend-specific. It's another couple of API functions. - There might be conflicts, in both the sense of ordinary diff application conflicts, and for Git, issues with the staging area. (There is a whole pile of logic in vc-git-checkin for dealing with the staging area with a comment summarising some of the issues, and there are still broken edge cases, I think.) I'm thinking that if the underlying VCS is responsible for handling the whole operation, it will manage to complete the cherry-pick anyway in more situations than our generic code will be able to do. It will also be faster, which might matter when cherry-picking a big chunk of a branch. Thinking about these sorts of issues, I am inclined to prefer cherry-pick-specific API functions. They're not hard for a backend author to implement, and I don't think they preclude adding an apply-patch and a fancier checkin-patch too for other purposes. (In particular, your apply-patch is very interesting, I agree that might be a nice addition for diff-mode. Then 'C-c RET a' would call into the VCS, sometimes. That's probably a separate bug though.) >> These are my proposed commands: >> >> vc-cherry-pick: >> - Gets the log message for REV with get-change-comment API function. >> - Gets the string to append with cherry-pick-comment API function. >> - Puts these together, starts a Log Edit session for the user to amend >> the message (e.g. for Git, doing C-c C-s to add a sign-off). >> - On C-c C-c, calls the cherry-pick API function for the backend to do >> the cherry-pick. >> Examples: vc-git-cherry-pick would invoke 'git cherry-pick' or >> 'git revert' depending on whether REVERT. >> vc-hg-cherry-pick would invoke 'hg graft' or 'hg backout'. >> >> Will have vc-checkin's COMMENT, INITIAL-CONTENTS arguments so calling >> from Lisp can skip the Log Edit session. >> >> A prefix argument might toggle whether to append the cherry-pick >> comment. > > That sounds like a bit of a waste of the prefix argument, since the user > could always just delete that comment. I think we'd be better off just > not having the prefix argument do anything for now, and maybe we'll find > a better use in the future. That works fine when cherry-picking a single commit, but if cherry-picking multiple commits, we're thinking there'll no opportunity to edit the commit message. In my experience cherry-picking, I want the cherry-pick comment often, but definitely not always. Git changed their default for this at one point; -x used to be implicit, now you have to specify it. So unfortunately I think we do have to give up the prefix arg to this. >> vc-undo-revision (vc-revert is taken): >> Same as vc-cherry-pick, except passes REVERSE non-nil at the >> appropriate points. No prefix argument. > > Maybe we could name it vc-revert-revision? > > Actually maybe we should name the commands something like: > > vc-revision-cherry-pick > vc-revision-cherry-pick-apply > vc-revision-revert > vc-revision-revert-apply > > To display more directly how they're closely related and symmetric. Yes, those are much better, thank you. (I would just say vc-revision-cherry-apply over vc-revision-cherry-pick-apply, though.) >> vc-cherry-apply: >> The advantage of having a backend API function for this is that the >> backend can use its full merging logic. >> A generic vc-default-cherry-apply can be implementated similarly to >> vc-apply-to-other-working-tree. > > Right. I assume that generic implementation would use the 'diff backend > function. And the sole disadvantage of such a generic implementation is > that it would have less smart merging. It would also be slower, probably, but for cherry-applying instead of cherry-picking, that's less important, because you are probably applying changes from fewer revisions. >> vc-undo-apply: >> Like vc-cherry-apply except passes REVERSE non-nil at the appropriate >> point. Similarly there can be a vc-default-reverse-cherry-apply. > > That sounds good, but... > > I wonder if we even need to support vc-cherry-apply and vc-undo-apply? > At least right now. > > Two very different reasons why we might not want those: > > - Those seem primarily useful when you want to actually edit the diff > before committing. But, it seems to me that using diff-mode for such > an operation is already pretty natural, and should be encouraged. > > The way I do those two operations today in hg is: > - Open up vc-print-log starting at some revision > - Find the revision I want to revert or cherry-apply > - Hit d or D to open up the diff > - Use diff-mode to do the editing > > Perhaps that is sufficient? I think you're right. Let's leave those two out for now. > - In a completely different direction: what if we only supported > cherry-pick, but also added support for git reset --soft? In git, I > often do cherry-apply by just cherry-picking and then resetting. This > is a bit weird, but it might save us some complexity if we want to > support git reset --soft anyway? There are a number of convenient workflows that I've used, and seen people discuss, which rely on creative uses of 'git reset --soft'. So I think it would be a very welcome addition. It also means one could immediately use these workflows and tricks with other VCS without learning about what the equivalent operation is, because Emacs would know. In generic VC terms, we could have an operation that deletes revisions from the end of the branch, and a version of that operation that deletes the revisions without removing the changes. The former would be 'git reset --hard' and the latter would be 'git reset --soft'. We already have vc-allow-rewriting-published-history which we can use to protect the user from getting themselves into an inconsistent state by means of these operations. I think we want to bake in the end-of-current-branch part. Here is what I mean. If we call it "vc-delete-revision", then it invites the question as to whether you can delete revisions that are not at the end of the branch. But that's a completely different operation: it's a rebase, not merely a reset. It's much less VCS-generic how such a thing could work. So I propose to exclude it. So I think we could call this something like - vc-delete-back-to-revision - vc-undo-checkins - vc-undo-checkins-back-to - vc-strip-revisions-back-to ? -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 11:07:36 2025 Received: (at 79408) by debbugs.gnu.org; 9 Sep 2025 15:07:36 +0000 Received: from localhost ([127.0.0.1]:59817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvzwV-000590-6x for submit@debbugs.gnu.org; Tue, 09 Sep 2025 11:07:36 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46221) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvzwN-00058d-He for 79408@debbugs.gnu.org; Tue, 09 Sep 2025 11:07:31 -0400 From: Spencer Baugh To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87bjnjlw7b.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Tue, 09 Sep 2025 12:08:40 +0100") References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> Date: Tue, 09 Sep 2025 11:07:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757430441; bh=zP5fMec4UUevuvHzt6eqgwuUULr4dJ3jQiUIvH3ZbYA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Q5LPJEoaidJeoyUolQAV3azvU/CN2yiE4sdh9/ZrR3s/GMj9iOIrs4rzm6x19brME oUiF25+2i4h7/uajJ6jooEyoeBb37klX8l7tS0Me8PKFK+53pgPggDaMF96LImpwW3 Iqira8ijszGxlvQlHCGccTGLarXTwo67I/H+5ebgyeXe/Rja8jtY9fGekBNdi8ditB R/e9AqMticUJyhEIkFPIQuYe8oOh3tgLzU6iWry1IipV7tIDI+GDxD5i8JJsDOb9al /7ucJHoYSrIi+RyWNQmPJOLlw8xLwYV5xwLS/wZdfCYSedPF02qpQ11ltIiqNf7RJq yyGA21LQZEX7A== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, juri@linkov.net, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Sean Whitton writes: > On Mon 08 Sep 2025 at 02:56pm -04, Spencer Baugh wrote: > >> This reminded me of how we don't have a way to do format-patch using vc; >> that's somewhat related, and would be nice to support. > > We do! 'M-x vc-prepare-patch' is the interactive entry point. Ah, right. I never use that because I always interact with Emacs development via Gnus, mostly via debbugs.el, and I just manually attach patches to my emails. (debbugs.el also has some way to format a patch but I've never gotten it to work) >> In fact, I wonder if perhaps: >> >> - a new format-patch backend function >> >> - a new apply-patch backend function (to take advantage of better >> backend-specific merging) >> >> - maybe a fancier checkin-patch backend function >> >> Could replace the need for these specialized backend functions? >> >> (I think git-cherry-pick used to be implemented as format-patch + apply >> under the hood, years ago) > > So, the generic code would be responsible for invoking format-patch, > then apply-patch, then checkin-patch, in that order, right? 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" > A couple of tricky things: > > - We would need a way to extract authorship information and then pass > that into the improved checkin-patch. An author's name and e-mail > address is generic enough, but the representation of dates might be > something highly backend-specific. It's another couple of API > functions. Actually, I don't think we would need that. The date and author information are both included in headers in the files produced by "git format-patch", and that information is used by "git am". Likewise, "hg export" produces patch files which contain the date and author, and "hg import" uses that information. The exact format of the patch is backend-specific, but I think we could reasonably rely on backends having some way to export a commit in the form of some header followed by a diff, which can then be imported again by another backend function. > - There might be conflicts, in both the sense of ordinary diff > application conflicts, and for Git, issues with the staging area. > (There is a whole pile of logic in vc-git-checkin for dealing with the > staging area with a comment summarising some of the issues, and there > are still broken edge cases, I think.) > I'm thinking that if the underlying VCS is responsible for handling > the whole operation, it will manage to complete the cherry-pick anyway > in more situations than our generic code will be able to do. > It will also be faster, which might matter when cherry-picking a big > chunk of a branch. > > Thinking about these sorts of issues, I am inclined to prefer > cherry-pick-specific API functions. They're not hard for a backend > author to implement, and I don't think they preclude adding an > apply-patch and a fancier checkin-patch too for other purposes. 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. > (In particular, your apply-patch is very interesting, I agree that might > be a nice addition for diff-mode. Then 'C-c RET a' would call into the > VCS, sometimes. That's probably a separate bug though.) Right. And if we're leaving out support for cherry-apply-without-commit for now, then we don't need to consider apply-patch right now anyway. >>> These are my proposed commands: >>> >>> vc-cherry-pick: >>> - Gets the log message for REV with get-change-comment API function. >>> - Gets the string to append with cherry-pick-comment API function. >>> - Puts these together, starts a Log Edit session for the user to amend >>> the message (e.g. for Git, doing C-c C-s to add a sign-off). >>> - On C-c C-c, calls the cherry-pick API function for the backend to do >>> the cherry-pick. >>> Examples: vc-git-cherry-pick would invoke 'git cherry-pick' or >>> 'git revert' depending on whether REVERT. >>> vc-hg-cherry-pick would invoke 'hg graft' or 'hg backout'. >>> >>> Will have vc-checkin's COMMENT, INITIAL-CONTENTS arguments so calling >>> from Lisp can skip the Log Edit session. >>> >>> A prefix argument might toggle whether to append the cherry-pick >>> comment. >> >> That sounds like a bit of a waste of the prefix argument, since the user >> could always just delete that comment. I think we'd be better off just >> not having the prefix argument do anything for now, and maybe we'll find >> a better use in the future. > > That works fine when cherry-picking a single commit, but if > cherry-picking multiple commits, we're thinking there'll no opportunity > to edit the commit message. In my experience cherry-picking, I want the > cherry-pick comment often, but definitely not always. > > Git changed their default for this at one point; -x used to be implicit, > now you have to specify it. Ah, right... 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... >>> vc-undo-revision (vc-revert is taken): >>> Same as vc-cherry-pick, except passes REVERSE non-nil at the >>> appropriate points. No prefix argument. >> >> Maybe we could name it vc-revert-revision? >> >> Actually maybe we should name the commands something like: >> >> vc-revision-cherry-pick >> vc-revision-cherry-pick-apply >> vc-revision-revert >> vc-revision-revert-apply >> >> To display more directly how they're closely related and symmetric. > > Yes, those are much better, thank you. > > (I would just say vc-revision-cherry-apply over > vc-revision-cherry-pick-apply, though.) Reasonable. >> - In a completely different direction: what if we only supported >> cherry-pick, but also added support for git reset --soft? In git, I >> often do cherry-apply by just cherry-picking and then resetting. This >> is a bit weird, but it might save us some complexity if we want to >> support git reset --soft anyway? > > There are a number of convenient workflows that I've used, and seen > people discuss, which rely on creative uses of 'git reset --soft'. > So I think it would be a very welcome addition. It also means one could > immediately use these workflows and tricks with other VCS without > learning about what the equivalent operation is, because Emacs would > know. Indeed. > In generic VC terms, we could have an operation that deletes revisions > from the end of the branch, and a version of that operation that deletes > the revisions without removing the changes. The former would be > 'git reset --hard' and the latter would be 'git reset --soft'. Makes sense. > We already have vc-allow-rewriting-published-history which we can use to > protect the user from getting themselves into an inconsistent state by > means of these operations. Hm, I guess you're saying we would allow resetting commits which haven't been pushed, but not (with nil vc-allow-rewriting-published-history) resetting commits which have been pushed? That seems reasonable. > I think we want to bake in the end-of-current-branch part. > Here is what I mean. If we call it "vc-delete-revision", then it > invites the question as to whether you can delete revisions that are not > at the end of the branch. But that's a completely different operation: > it's a rebase, not merely a reset. It's much less VCS-generic how such > a thing could work. So I propose to exclude it. I agree that we should only operate on HEAD/tip, and the name should connote this. > So I think we could call this something like > > - vc-delete-back-to-revision > - vc-undo-checkins > - vc-undo-checkins-back-to > - vc-strip-revisions-back-to > > ? vc-undo-checkins might be confusing because actually this command can also be used on revisions which weren't created locally by vc-checkin. The "back-to" names feel a bit verbose/clumsy to me. 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". From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 14:04:26 2025 Received: (at 79408) by debbugs.gnu.org; 9 Sep 2025 18:04:26 +0000 Received: from localhost ([127.0.0.1]:60760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uw2ha-00027r-DP for submit@debbugs.gnu.org; Tue, 09 Sep 2025 14:04:26 -0400 Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]:52304) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uw2hW-00026l-OE for 79408@debbugs.gnu.org; Tue, 09 Sep 2025 14:04:19 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4cLsCG0kzyz9t29; Tue, 9 Sep 2025 20:04:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757441050; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TEOBjbZXMAOXrfFexS934MNC8NN1lMe1kMojvtdevrs=; b=b46XVTyDL5ScMpmSVyhBtt0ZRQ4Y71CvKST5cF9rCF3DXmqCc6tjbf4M2bo4PVAzCvhhWe 9Zl3tnV5rfybWZnOfLIRQ1qjE00AVVM6251G/jZhO/mgtAAaYbwlkmpwJDaWaUa3dKLkSz BZtuTvWw1v4DP+4Fo9Exrq288OHL+0mDKL5ZOsnK5T4sXfX2XQTePMHi9ZOh0up17Qi2q3 BvUgn5lQth1fGu+Yrxb6QhRrY0n30+cdDdb2oMomcXUswPJ73Wos7Is1ZyCJBuBgNnUKui gmvamRLMbMGWdevjYthmrDlc7r8i9QSwV+8FPIgzGGGa8JOwdNyqbwPul/GIBA== From: Juri Linkov To: Spencer Baugh Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> Date: Tue, 09 Sep 2025 21:01:36 +0300 Message-ID: <87plbza4jj.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, Sean Whitton X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> This reminded me of how we don't have a way to do format-patch using vc; >>> that's somewhat related, and would be nice to support. >> >> We do! 'M-x vc-prepare-patch' is the interactive entry point. > > Ah, right. I never use that because I always interact with Emacs > development via Gnus, mostly via debbugs.el, and I just manually attach > patches to my emails. (debbugs.el also has some way to format a patch > but I've never gotten it to work) We still miss the command with a name like 'vc-attach-patch' that would attach a marked revision to the current message. >>> In fact, I wonder if perhaps: >>> >>> - a new format-patch backend function The existing backend function 'prepare-patch' already uses format-patch in 'vc-git-prepare-patch'. > 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. Using backend commands to do the work would be more reliable. Then as post-processing we need to update already visited buffers. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 14:22:55 2025 Received: (at 79408) by debbugs.gnu.org; 9 Sep 2025 18:22:55 +0000 Received: from localhost ([127.0.0.1]:60974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uw2zW-0004hG-GS for submit@debbugs.gnu.org; Tue, 09 Sep 2025 14:22:55 -0400 Received: from mout-p-102.mailbox.org ([2001:67c:2050:0:465::102]:32840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uw2zQ-0004fT-HH for 79408@debbugs.gnu.org; Tue, 09 Sep 2025 14:22:51 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4cLscc5pq6z9tJm; Tue, 9 Sep 2025 20:22:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757442160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oqtjzx1uAadyQ0bn4EltiM0AL4O5iaN5mvLArhFIwGw=; b=oXhLEy4BhFtWgAKKLOzuL8KVHRh+iICDifffYhY85+HT9JaqvuIzeAe14tIHY2nYUKq3g3 0frt2DoEPUdVJ3IaLLn+6xhGpN3mur0XvfxFkPiELy9NyNyOlbT0IKf+WJT9ZNE0HtfSzT 0MYMUg3rb1xVd5EDrd+oMsNR8aZRvOExXnaY2oxmWBeXbovH/lBSjWBiD67iD5GF33zCBt Lftsscl4pC7+0e02cG5JOOo3cA220cDajJx7KCEokmwGO05Oc2YLfhTXBfZXq+2TsRYndC mMGU0ZotEfBPZQRjgCBquAVOXcezRRZXpYy2a1az6f3CscQTSaXEqTjtxF6++g== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::102 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87ikhskkxv.fsf@zephyr.silentflame.com> Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> <877by8kd3o.fsf@mail.linkov.net> <87ikhskkxv.fsf@zephyr.silentflame.com> Date: Tue, 09 Sep 2025 21:15:19 +0300 Message-ID: <87cy7za3wo.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cLscc5pq6z9tJm X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> I guess the basic workflow would be to view a branch log >> with e.g. 'C-x v b l', then after marking the required commits >> invoke the new commands. > > Right. 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; - type 'C' to copy or 'M' to move (actually 'R' in Dired); - select a branch name in the minibuffer with completion. >> Are the last two commands equivalent to showing diff and invoking >> 'C-c RET a' on it, with or without the prefix argument REVERSE? > > Yes, except that using 'C-c RET a' uses Emacs's merging logic, which may > be less sophisticated than the backend's. Hmm. Maybe I should skip > those commands for now. What do you think? I think it makes sense to implement these commands only when they use backend commands. Because using diff commands is already easy with 'C-c RET a'. These new commands could provide an alternative way by relying on backend commands. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 10 05:53:27 2025 Received: (at 79408) by debbugs.gnu.org; 10 Sep 2025 09:53:27 +0000 Received: from localhost ([127.0.0.1]:36091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwHW2-0004r8-Nn for submit@debbugs.gnu.org; Wed, 10 Sep 2025 05:53:27 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:45502) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwHVx-0004qi-Mv for 79408@debbugs.gnu.org; Wed, 10 Sep 2025 05:53:24 -0400 DKIM-Signature: a=rsa-sha256; b=raNNAtcBq3o9DJrI/hiph06192p60PdAa/d9WY6RXwTTvlp3Uedlr3bQY2frVXZR8Z2aR6GDWwSAR1ZO3n0A3Qyr4p9SdYPYi2gtKZc3YLouC3Kt8APgDxFzEHBXEP9PZG/SnqRdSyqiV8fnpKN2uWdc20scUaSi2zXBYywUkS1SFYjiZKxqXPPoiKLUkiW9y4PZp6/Bd6tHUzMfddqHpH2B4aDOtwNY3BPCbprBv7w4+D1fxCWX91tZ6vqv4YNFY2fbYJ1AiMIlgq49p3wTElFt+giMrmNrIXB7XeUvwqylMDdXRMyTDKDfVE4BBjLW7ElBWjb2dNtHO7ELgjWMHQ==; s=purelymail3; d=spwhitton.name; v=1; bh=Qu0/A5vwGn1Vs0s+fjqWiKXz2OBtKxtE8rFXdtmXDFM=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=ke5e6XljsTVTVflBKbnJZzK9osO26bNJZSrZ366cd2A2mg6um1EezJd+oHKrMEsrA7dxXxsVhaJ/2fb/36I8UFck4b17v2fHm6YpwC98AP5BRxpWQTfyN5KoCdjoYOrn44sSJOdPTB81sxTqmCCmgTgR7efJGqlR0BI2cIdX5wZHAz6P5n04a61lwfG1rb7/kGCOmKsacjScOmS++p4lhElsDDxc+gkObtZjG23c66KxAczR33jLzvtZb6lBKnG2lphOaxAJxopWI6cYOSiV534hCMA5uiOeQCesKDgYezZLN2SHL52StTDNh98MYvaqfgEdmb8QnZ1Fp4asVpwfLw==; s=purelymail3; d=purelymail.com; v=1; bh=Qu0/A5vwGn1Vs0s+fjqWiKXz2OBtKxtE8rFXdtmXDFM=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 234505445; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 10 Sep 2025 09:53:14 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 5334F940D2C; Wed, 10 Sep 2025 10:53:14 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87cy7za3wo.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <877by8kd3o.fsf@mail.linkov.net> <87ikhskkxv.fsf@zephyr.silentflame.com> <87cy7za3wo.fsf@mail.linkov.net> Date: Wed, 10 Sep 2025 10:53:14 +0100 Message-ID: <87seguk511.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, sbaugh@janestreet.com, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Tue 09 Sep 2025 at 09:15pm +03, Juri Linkov wrote: > 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. 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. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 10 05:54:38 2025 Received: (at 79408) by debbugs.gnu.org; 10 Sep 2025 09:54:38 +0000 Received: from localhost ([127.0.0.1]:36101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwHXC-0004u2-5X for submit@debbugs.gnu.org; Wed, 10 Sep 2025 05:54:38 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:44514) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwHX7-0004tU-MH for 79408@debbugs.gnu.org; Wed, 10 Sep 2025 05:54:35 -0400 DKIM-Signature: a=rsa-sha256; b=NX7RSGsh4QlM+PsSwwrRNLOZ/vNZUNcZA5QmD/ggemtc1UgJdxf9xGJFGTmTwhs309zW28LZdUeK1e5yZC1J1k+5CXLP2aE4usWPmwAuVJyGWEcA+RQ2nZLMuAHLOyUNv8l56lOnBnlwvK7n3Y3vUjHUILWVu6oJzJV8OC9oHOCyuiQ/kSEygzgnCYHTjKQ+/NPQTv8xoMXIQ5vT7U+eY7JA8LiI8V+0588p6gOdjPlXZjJxjQCF865agN4A0OFalr2vA/070jVKPW4S2uIpDnpgePVFJJJ5RNSDsfjtsl0kus7awMCgpxIUxl5S2iMSVBaACJk/zcjVZZc47to7Ng==; s=purelymail3; d=spwhitton.name; v=1; bh=ioVd+ON49+LcHSbCUgU82kD3ZBNiHL4/H/RiWgIe8ZI=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=CPSti/T2VhsjVI2LryACzGoBDAeDZJOlkbVoI6sMasyZCXWT5yQ75tCMFrhtvzs9i1ZQ4FB32h7RzCUZPutiFqQh11Wex/0FXnxruHxgK8J2BykpoZxu55eGf81EkByO8dgodUNo9wak7Jf9HD7tcHhi4eUvHw9Dc3VGmugaQqBnXi8MSqk0kEUXI6/RGs1gi+xEcR3nWuW31YlhlBnl4ZfIl74+J22LdKH7JjV5V01OTDAI4PyDxCYqA70oGcGrEphdDTC2YAoEsQa1IxFvFfZiAH8FIyhLXbFad9r/+I4BjpzmbF3Rl3AvkZRpbrVg9jNYtW2w69F2mp7oEH3pUA==; s=purelymail3; d=purelymail.com; v=1; bh=ioVd+ON49+LcHSbCUgU82kD3ZBNiHL4/H/RiWgIe8ZI=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1195310695; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 10 Sep 2025 09:54:26 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 755BB940D2C; Wed, 10 Sep 2025 10:54:25 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87plbza4jj.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87plbza4jj.fsf@mail.linkov.net> Date: Wed, 10 Sep 2025 10:54:25 +0100 Message-ID: <87o6rik4z2.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: Spencer Baugh , eliz@gnu.org, 79408@debbugs.gnu.org, dmitry@gutov.dev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Tue 09 Sep 2025 at 09:01pm +03, Juri Linkov wrote: >>>> This reminded me of how we don't have a way to do format-patch using vc; >>>> that's somewhat related, and would be nice to support. >>> >>> We do! 'M-x vc-prepare-patch' is the interactive entry point. >> >> Ah, right. I never use that because I always interact with Emacs >> development via Gnus, mostly via debbugs.el, and I just manually attach >> patches to my emails. (debbugs.el also has some way to format a patch >> but I've never gotten it to work) > > We still miss the command with a name like 'vc-attach-patch' > that would attach a marked revision to the current message. I have something like this in mailscripts.el, an external package of mine. We have all the pieces to do it in core, though, and it would be useful indeed to be able to do it by marking a revision. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 02:56:52 2025 Received: (at 79408) by debbugs.gnu.org; 11 Sep 2025 06:56:52 +0000 Received: from localhost ([127.0.0.1]:41932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwbEh-0002z3-NV for submit@debbugs.gnu.org; Thu, 11 Sep 2025 02:56:52 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:60612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwbEf-0002ya-2U for 79408@debbugs.gnu.org; Thu, 11 Sep 2025 02:56:49 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4cMpJ92LQnz9tvd; Thu, 11 Sep 2025 08:56:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757573801; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QcQp8JrFXw2STh3csOF2vvLbtPOqicSiQAymdShPqmw=; b=mdSryX1yBiZKJrtzswBUFX1aLbO0jHcZFZxLqTSUKV9Fa2rXLcA7oKUbS89GmXMbVP2/ZR znnV9CeuopVkf7L5KnzmOeNrYYci3X5GLiQYjDrdgQiObzc+8p0jUBFfVrVEBNM2HjRmiA xZ7EkuwlVeuH+49awUa/xsj3Efv3bfazR+b0pkygsVMAyKdYoFsmzgfKDu5GPdC3QRylkH XrJDdPzmGJOkhBzAdDRJMN5mw+k6JlS+h0mTM9cHUqsiGjOxFEXEzQdJIOWs0GXn7+GQbJ JCS26dP9b0L/YiFCzwqQkKXxXd95/sT5YnUc2KqEBT3Dfp6CASq+vPqYGRQqUA== From: Juri Linkov To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87seguk511.fsf@zephyr.silentflame.com> Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> <877by8kd3o.fsf@mail.linkov.net> <87ikhskkxv.fsf@zephyr.silentflame.com> <87cy7za3wo.fsf@mail.linkov.net> <87seguk511.fsf@zephyr.silentflame.com> Date: Thu, 11 Sep 2025 09:55:37 +0300 Message-ID: <87ms71o4uu.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, sbaugh@janestreet.com, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 06:22:53 2025 Received: (at 79408) by debbugs.gnu.org; 11 Sep 2025 10:22:53 +0000 Received: from localhost ([127.0.0.1]:42709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uweS4-0006zx-13 for submit@debbugs.gnu.org; Thu, 11 Sep 2025 06:22:52 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:36048) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uweRx-0006zX-HH for 79408@debbugs.gnu.org; Thu, 11 Sep 2025 06:22:47 -0400 DKIM-Signature: a=rsa-sha256; b=Jz6E9KFZ/virmpk2xah9RXg8ibmnlfbXTMHdfBYwi61dfbZ7ATb662zn3mKXOOYKQ6pF4RWxw6e1Ss3gMlzyFp/0ji4Djvh4tnwVhNN+BZ3UNiltxnJiYPuAbEixxc2BBtYjmTgdPDW0w/VUvPKM1q8eOegD5c94+ApxJcMx3e1yFovZVLrTRHEPe8u5VgU7/psSG66ZKEhcewFUSSk7SwQ4ynAGHXMGaEy+26CtVoAym14CFg9JDM2eM/9AGK+7idan4IkY6Vcglbe3LKPTtazaghdWngrzJBI12CrjFiduvYuCbe5E+Zo+C08QiAXyrMrCnTjpZSuGPeG+A2jn2g==; s=purelymail3; d=spwhitton.name; v=1; bh=He2paLlbse59fujFE7G9W7HRIL08atAioyjk3/WGyGM=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=Wwy1n3aIrcYt64gC7UAQtYhwQnbUHUt2AuLEBL8i1Be3o+6sdzg6osxYsoqZmRZg2SY0jiRmCvucQrhFEopMOxG5u4KkIzqevIYtztvVPeZbOqZ1Mf4fMpT3KJ0S6//durlgjzWVsuV1+2GVmINHK+0BNthudRL8kx0xTlsA2TUStylzLeghAHNtaClY3AY9D/U7oz8IjR5uJBgrpTHu8b3fiF7QXfvEsPebls5MIp08bIcLMelaHKevT+DGwLxO+wlnBmACo3Dckg8mU11bBAeQjVedk3GjdYtQAVggFER2PR008T8nGpbwdOKxN+cfMpW4hGqEztEaWlI9H7L56A==; s=purelymail3; d=purelymail.com; v=1; bh=He2paLlbse59fujFE7G9W7HRIL08atAioyjk3/WGyGM=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -728345462; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 11 Sep 2025 10:22:37 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 60893940D2C; Thu, 11 Sep 2025 11:22:35 +0100 (BST) From: Sean Whitton To: Spencer Baugh Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> Date: Thu, 11 Sep 2025 11:22:35 +0100 Message-ID: <87ikhpjnkk.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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.) > 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. 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. 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? >> We already have vc-allow-rewriting-published-history which we can use to >> protect the user from getting themselves into an inconsistent state by >> means of these operations. > > Hm, I guess you're saying we would allow resetting commits which haven't > been pushed, but not (with nil vc-allow-rewriting-published-history) > resetting commits which have been pushed? That seems reasonable. Right. >> So I think we could call this something like >> >> - vc-delete-back-to-revision >> - vc-undo-checkins >> - vc-undo-checkins-back-to >> - vc-strip-revisions-back-to >> >> ? > > vc-undo-checkins might be confusing because actually this command can > also be used on revisions which weren't created locally by vc-checkin. > > The "back-to" names feel a bit verbose/clumsy to me. Fair. > 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). 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. 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. 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. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 06:23:44 2025 Received: (at 79408) by debbugs.gnu.org; 11 Sep 2025 10:23:44 +0000 Received: from localhost ([127.0.0.1]:42720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uweSt-00072l-CW for submit@debbugs.gnu.org; Thu, 11 Sep 2025 06:23:44 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:45522) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uweSm-000724-1M for 79408@debbugs.gnu.org; Thu, 11 Sep 2025 06:23:38 -0400 DKIM-Signature: a=rsa-sha256; b=sdA7iZrU1TWo5Ksj3HByGGx+b0W7O1OMjC3bIUqRrHMEVwEH0b734aJ1vyjN9gD8L0ZFaD61EsYpHDtM9M2ggKXW86+8VFOjOWQALqRsT+d67aYjJ3lpw1ndBc9+GadhaGnPOYPGYU/8izg2AADLJt9HZ7qtmzpW+w6uJh1bd7vL/bUSVpdmb2Y46aWUZybQx3cHbqjy4vCOpmn/M4cH9xfv/jBkdDRUtNlF44DBVwJvHrACz5xxun4Nz4Az1DlIcOtSOdRANNKPEJGQs+NtC06XcqcpVCD4T6chBnorO/YjLVdxJy7kldLnGF7OhI+zejtZoYETBACJVDyzkcSQuA==; s=purelymail3; d=spwhitton.name; v=1; bh=ja9GxUPjpxTwTo5lNx6+6SSs1UsrMsA7Aw5Z8a+M0R8=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=jYKxwAJNvVn4Sq1Q9Ycoivin9HluLZfoKkiNwKufM0PX8eIgVFWlBfV2dDm673HNyg23akY5J7/QLlZDtU/8Vs35l1EmYrnUP9kRxsfV6hyLY1rvS+jXdaUVODH/epdDSnXsDsyHg6da2Asfdb5Ftwk61rDRKINMlWq194Kk1y10js9wr9OeUDsr1g+P65KsG8z/DpcwwCe8m73KN8dJg64QmEbIz9QCq9ga4LlyAp6CDVcz6l296xh7QMOHCiLA9so2k+5QI7V8iSUoW2CURSp1a/EV8wms9IsQmgHZCljPQZzBLoMGNkTTzggIayLhe5gOWC4XVxq9VT3FAJmO8A==; s=purelymail3; d=purelymail.com; v=1; bh=ja9GxUPjpxTwTo5lNx6+6SSs1UsrMsA7Aw5Z8a+M0R8=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1977352595; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 11 Sep 2025 10:23:28 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id B6F23940D2C; Thu, 11 Sep 2025 11:23:26 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87ms71o4uu.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <877by8kd3o.fsf@mail.linkov.net> <87ikhskkxv.fsf@zephyr.silentflame.com> <87cy7za3wo.fsf@mail.linkov.net> <87seguk511.fsf@zephyr.silentflame.com> <87ms71o4uu.fsf@mail.linkov.net> Date: Thu, 11 Sep 2025 11:23:26 +0100 Message-ID: <87ecsdjnj5.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Thu 11 Sep 2025 at 09:55am +03, Juri Linkov wrote: > 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. Yes, I think so. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 13:22:19 2025 Received: (at 79408) by debbugs.gnu.org; 11 Sep 2025 17:22:19 +0000 Received: from localhost ([127.0.0.1]:44657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwkzy-0003dn-Ol for submit@debbugs.gnu.org; Thu, 11 Sep 2025 13:22:19 -0400 Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]:54556) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwkzo-0003cy-BA for 79408@debbugs.gnu.org; Thu, 11 Sep 2025 13:22:14 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4cN49h3nb2z9tZX; Thu, 11 Sep 2025 19:22:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757611320; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=A9IwzA4KwGqIje9jAw4Y6AqxnSWTp8MMfKnf7qDcN3Y=; b=DgRjCmer1d3YyT99Bmr5q0YLlyviIS7bWyRcaPeK8eFjQzbsexdYVWsQENIUdeEe1rLfgM gFN7PA8+VDToj1EClqTzUC4M1PS04hwK3bYpxroO88h/3cjUohRk7SMVUAEQlITV3T/K7P haWe3WaH7KgWadTUq2tDdANJwYJawBkvyvRJJA+lE+xp3/nazK0Qm8LTFaGNuMrmMrANOJ uMKdkSz253HcAAggAcKO8nIdyk3LW3RbeXI6UAP7dNazFJJ87of8SaVHm9VFeWO9JPJ4cd kuuTKxyGt5pioUzjj3pk1ECwPc93q/+kPXX1YJ1Rws5BENhjLO7RemqFFkES6A== From: Juri Linkov To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87ikhpjnkk.fsf@zephyr.silentflame.com> Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> Date: Thu, 11 Sep 2025 20:18:44 +0300 Message-ID: <878qikkivf.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: Spencer Baugh , eliz@gnu.org, 79408@debbugs.gnu.org, dmitry@gutov.dev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > (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. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 14:15:02 2025 Received: (at 79408) by debbugs.gnu.org; 11 Sep 2025 18:15:02 +0000 Received: from localhost ([127.0.0.1]:44760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwloz-0006gm-KM for submit@debbugs.gnu.org; Thu, 11 Sep 2025 14:15:02 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60961) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwlov-0006gJ-Q5 for 79408@debbugs.gnu.org; Thu, 11 Sep 2025 14:14:58 -0400 From: Spencer Baugh To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87ikhpjnkk.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Thu, 11 Sep 2025 11:22:35 +0100") References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> Date: Thu, 11 Sep 2025 14:14:52 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757614492; bh=ivbKEoZsK0GzKIaY/F0TxyOrFjYNKLaqY5d2wHgCncY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=dn06WZOQtN96qo3nKKOffwqnh7NeuKokhxPXeT1/WuNbEcW2ysQeGrTGacaohjZKE lSsS2pA1zGKN8bQCxBPt3XA5P00NB2b5Ak0qJFU33Y338/UxsAf6P/4D5clk/8Mrcu 5amkth1wKXZDG7e+XhsL4vStzaaVAEl7lPNDNmMYLWZJ1OS25kyuflX5OQLmXH5wRC ph/HAsflq+MO8bcFs2FoKU5/IqJdSmK/ErJhrGFW9CI3Fa5PAAXu8V2jgmylxkN4Bk GkrP/msRAScCZQdYksCmV/tf5OUZQn7DFWwM/LfzLFO8/fcsVWzlpykkx19oykJ6At NXPD+1ufqz2NA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, juri@linkov.net, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Sean Whitton 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 12 05:57:44 2025 Received: (at 79408) by debbugs.gnu.org; 12 Sep 2025 09:57:44 +0000 Received: from localhost ([127.0.0.1]:48685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ux0XH-0006NX-Fk for submit@debbugs.gnu.org; Fri, 12 Sep 2025 05:57:43 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:35162) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ux0XE-0006NC-6z for 79408@debbugs.gnu.org; Fri, 12 Sep 2025 05:57:41 -0400 DKIM-Signature: a=rsa-sha256; b=myT7glc+X6EqjWCBNm62y6THxzCDaiZ/5wVCn7cFFKJyKC0KIFhRpdIYoGxZdCzGTgdhFrN/zrInkqItxDqBGL3jMMhHjruKIPRdCFGhl5whlBpNxyY+A3Ox6J4lyXCrg+wqasSOUN8OtsSBTSgx5kWQkt+4sztUOz2Z7CZ+Wks7mjpKvNb7Y6LStXLSls3HOSH7b+crAEpvNze10zDEMAvIVgmTss98RB/5VdHB61UsMlkH8btQudSuyxqOoMLkhfpXZ6pTRQotrP4S7YZiS3zkWCgoBCsWlyZNlD7efRWsvoYFuU8v4VNlrijiuTramqNMqFfDVA+elAkxsFuAXQ==; s=purelymail3; d=spwhitton.name; v=1; bh=dyB1CeZOn0MIzIjitb6BLqnMQiAKKe6qWgyXE+FN5Mw=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=Ws5M0qEtaC1GHl0SsRIwMSyp/TLMnlNBNy9m0YjLwpg3+axvpOqb3ehLoncvgrZlKl8yrDQSe37dOsY02UXi40o0gy3yvnOSOL24VrFbj7AtXWpHUyzrDEYDztvOc7OqPJkthIR1R6Sc3BD4OB2D4U2zNjky2NoCvX08/9TiZ1LnjxjAsmVdXZrLtGuUe0kB4UFba/AGcCX9s9fnm4qrquFmkvCGHsVqoHy8xby1DDajoihhkfcrtBQ5Zum+bhd9NWolI1CuR0uD8BQVxyHgml2NfFmPIvBa+v2mWkAd2uqXVajITjiu4nhsklzQm/Z/HxUJsND3YwBrAwpfu73icQ==; s=purelymail3; d=purelymail.com; v=1; bh=dyB1CeZOn0MIzIjitb6BLqnMQiAKKe6qWgyXE+FN5Mw=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -2070855540; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 12 Sep 2025 09:57:33 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 1B484940D8C; Fri, 12 Sep 2025 10:57:33 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <878qikkivf.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> <878qikkivf.fsf@mail.linkov.net> Date: Fri, 12 Sep 2025 10:57:33 +0100 Message-ID: <87cy7wgfhu.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, Spencer Baugh , eliz@gnu.org, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 12 08:55:23 2025 Received: (at 79408) by debbugs.gnu.org; 12 Sep 2025 12:55:23 +0000 Received: from localhost ([127.0.0.1]:49418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ux3JC-0004RY-QT for submit@debbugs.gnu.org; Fri, 12 Sep 2025 08:55:23 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:53448) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ux3J6-0004QK-BB for 79408@debbugs.gnu.org; Fri, 12 Sep 2025 08:55:18 -0400 DKIM-Signature: a=rsa-sha256; b=MUPMyuIyAcvu+Z27ruoJJzbwDV9eZSMF6um5ZzHatrXnQSAy6f24/4DbiaJlHv2EZuv0xMwx5MWb1sQci9ZU897TD7LI3Ny449pQEd/aduyk1MmFObplXwkiz+VfNFRVb9kWwQy42DJa318fvc0p/W1eka0SME/BQXdjanXeh8MXa+jCb/BqLUKqAwIt8/Q7tHIWoxbW8MmuqwSr8XfSxsIE33m6H4p4qwTVEiuwV5C2p9ukfg45eD0y1NP8PBlRgV1Wl0Fl5Do3QzZaX7bNf9t3J8jndKm1eqMEa2OnkqngHldWCeZJP1zwidBRXh2aK+iIyW9zR8Anfa2/Hws0qg==; s=purelymail3; d=spwhitton.name; v=1; bh=WzytY67Jez7LEMRA7wOyYyjmzYKG92hvEB80yxl8Nf0=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=tvuh+BH9eCwDiQeHqyIq8nGiPv4+n0NmnkCtq+geRUiKCTCg2l0PTnJ2tCS7rW+ttoPu8MOc9tHN0WUFL0ixT6oZHHTiH3sOj4rQ/nUPz8sJsysneKvHFpEvPCWvzqWo6ncN3i6EJVg24epvHKpzIZXYvGtitzwn/QMDsoOmQkrsZmezW958JCQY7QpfamD/tEFQPI/J8Lp+PEgfh+vgof8xNCfMX4gtUVNvBFRC0Wqgn6e+7ey0hscFyvO/9tkQZPOxUPysiD7INJaKqmUbIgecF39nTQgeAU5KrJ7NfO+pBiEg5Lt6JZIhcKZipt3B6gS7L7JJhb8Xe2fPv2RNmg==; s=purelymail3; d=purelymail.com; v=1; bh=WzytY67Jez7LEMRA7wOyYyjmzYKG92hvEB80yxl8Nf0=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1560786548; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 12 Sep 2025 12:55:07 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 40945940D8C; Fri, 12 Sep 2025 13:55:07 +0100 (BST) From: Sean Whitton To: Spencer Baugh Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> Date: Fri, 12 Sep 2025 13:55:07 +0100 Message-ID: <878qijhluc.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Thu 11 Sep 2025 at 02:14pm -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > 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. It's already supported for Git, actually, on master. You make an interesting point. At the end of a multiple commit cherry-pick, we could display a non-shortlog Log View buffer with just the result of the cherry-pick, and display a message saying "You can use \\[log-view-modify-change-comment] to modify any of these messages". That might be perfectly adequate and also means that when you don't need to make any edits, you're already done. > Interesting idea. That same kind of UI could also be useful for > interactive rebase, I guess. Potentially, though I think full interactive rebases are probably out-of-scope for VC because they're highly VCS-specific. > Personally I think custom.el-style text fields are also pretty clumsy, > so I'd avoid those. Yeah, especially when one is used to a full Log Edit buffer for editing commit messages most of the time. >> - 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? Yes, I agree, vc-revision- for all of them. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 12 12:20:31 2025 Received: (at 79408) by debbugs.gnu.org; 12 Sep 2025 16:20:31 +0000 Received: from localhost ([127.0.0.1]:50822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ux6Vi-0000la-1R for submit@debbugs.gnu.org; Fri, 12 Sep 2025 12:20:30 -0400 Received: from mout-p-202.mailbox.org ([80.241.56.172]:57246) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ux6VS-0000hD-QR for 79408@debbugs.gnu.org; Fri, 12 Sep 2025 12:20:22 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4cNflm47J7z9tRG; Fri, 12 Sep 2025 18:20:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1757694004; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4thanRD8GzrxVv/ZR5oExjmHf4yZZuo3bIILDYVIWEI=; b=odUJieB3Zp0/p1w+1DMkiGtTF9aXmB4TA8WHp4x3jcXHD1H5Ya1Lf+lc18peYf42pH+ZCC mPWy+5YahU6DjFI4QwNpckg2xdzJR2YloiTG/39hT33TKL7OOMJejHZWZDKdFa3YZAw4h3 +p5+YazFqOQ6DHkJWTJLosO5k6YIaIUdmaIGxS6UMaLkOL7GPs7GrDT7c1ydGZ1gpT0Ulq TVRxIHPsS/2gCiaDrPYKZGXthSJ/kxWfeUTqXmuFu6hSqKL6riNe2IaNJiq/hUQkc3qOdt 0I9bQbLfzJ7JSGPU9zSEb8qc71sjkT80+9KuuXxfU1A0aWkGtW/huRvr8AWDUg== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::202 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Sean Whitton Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87cy7wgfhu.fsf@zephyr.silentflame.com> Organization: LINKOV.NET References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> <878qikkivf.fsf@mail.linkov.net> <87cy7wgfhu.fsf@zephyr.silentflame.com> Date: Fri, 12 Sep 2025 19:03:29 +0300 Message-ID: <87plbvtzrq.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cNflm47J7z9tRG X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, Spencer Baugh , eliz@gnu.org, 79408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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. Another possible variant: 'rollback' - that name is also used elsewhere to revert git-based deployed releases. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 07:46:19 2025 Received: (at 79408) by debbugs.gnu.org; 13 Sep 2025 11:46:20 +0000 Received: from localhost ([127.0.0.1]:54142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxOhv-0000nv-Ac for submit@debbugs.gnu.org; Sat, 13 Sep 2025 07:46:19 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:43160) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxOhp-0000nC-Ga for 79408@debbugs.gnu.org; Sat, 13 Sep 2025 07:46:15 -0400 DKIM-Signature: a=rsa-sha256; b=AACZ3fUK/aK8Ag5jo7CLbv7kLZbvt7Z470DirIIp/tQaPQ+sUFxzQ6uKC/rRMIj+UTFamlly2u3ChajzEOuBDo0eS4fDT/F8UqFiqphAM3HZ3oQfBfOcuia4XfIR9E247+pT/hGb4LX4MBcaKW15+GHDad+dfCQ+gcLuUCEkjadvBOWHucnyMIc6xnKqgI3RjmIjVz7ClwnGUH+oPtfgeWMG7vD2HpnE03n4eVnWGHXTjAWw/gwzHRIQuKy7MV3E4GtiwUK2gOsU7wUXOizRmGuc2qlok/BtaSgfVtJwYSbezj0LL6WRz2qtw7D59TAaGlcdTFvHPcQuTliy5zlVhQ==; s=purelymail3; d=spwhitton.name; v=1; bh=kMVaEtI5z+W9pEjsUQCbIRBaOM8LpboY+EEEGPz0RaY=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=gRFFiJ2twWPGuMg2brs6hnpHs9me2mgWwco8XwjHUVRRVKOOsp6YkMYyLcZpGu+bsPhx2QVSDmRASKiGbbL8pk9Cdsh9qbz3zx0dnry9sv62kI4PeXd/oYbQEpGGN6iQzkfS/8Uh8MMI8KLRdUku/wZsuzvX69OZejM2GmULIx11ZCun4wp3md9sVE5res43O3exMGqluEEuStLsJla0D/Ets3Q1FbTPxzyudNYCkNBqJPRDQC2mRNpXpkjWC8BidxNttbyI0+Znbm0JOAhAzGsPEb2rjcjpDMfwl3iRAFich8oHy4GrUmGvEvnANXp7dIh8vGA3danUI6MyNCWO5A==; s=purelymail3; d=purelymail.com; v=1; bh=kMVaEtI5z+W9pEjsUQCbIRBaOM8LpboY+EEEGPz0RaY=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79408@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 904634505; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 13 Sep 2025 11:46:06 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 98FFD940473; Sat, 13 Sep 2025 12:46:04 +0100 (BST) From: Sean Whitton To: Juri Linkov Subject: Re: bug#79408: 31.0.50; VC commands for cherry-picking In-Reply-To: <87plbvtzrq.fsf@mail.linkov.net> References: <87a535mbg9.fsf@zephyr.silentflame.com> <87bjnjlw7b.fsf@zephyr.silentflame.com> <87ikhpjnkk.fsf@zephyr.silentflame.com> <878qikkivf.fsf@mail.linkov.net> <87cy7wgfhu.fsf@zephyr.silentflame.com> <87plbvtzrq.fsf@mail.linkov.net> Date: Sat, 13 Sep 2025 12:46:04 +0100 Message-ID: <87qzwafudf.fsf@zephyr.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79408 Cc: dmitry@gutov.dev, eliz@gnu.org, 79408@debbugs.gnu.org, Spencer Baugh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, On Fri 12 Sep 2025 at 07:03pm +03, Juri Linkov wrote: >>> 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. > > Another possible variant: 'rollback' - that name is also used elsewhere > to revert git-based deployed releases. I had a thought about this just now. Maybe "pop" for stripping commits without stripping their changes, 'git reset --soft', and "strip" for stripping commits and their changes, 'git reset --hard'. -- Sean Whitton