Received: (at 80006) by debbugs.gnu.org; 23 Dec 2025 12:26:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 23 07:26:14 2025 Received: from localhost ([127.0.0.1]:55542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vY1Sw-0000P5-9L for submit <at> debbugs.gnu.org; Tue, 23 Dec 2025 07:26:14 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:42544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vY1St-0000Ol-PX for 80006 <at> debbugs.gnu.org; Tue, 23 Dec 2025 07:26:12 -0500 DKIM-Signature: a=rsa-sha256; b=cedVn0/4bPU/qgcfsvoJmC1t8iXPm4yaqWwjrtpYS8jRj5xJVjlGEvjNr2kQ+EWUjp4R6QZfUyuNVPS3WD7erY6QzB+nGbwElC1+ENikPwLSYzlLPTmXdmoiRk2yCWaF+yzlfv6j8f5VicxSviQWcHGHuva45z1JeOUZjAT+/QkXCKnLVkS+/hNcjssYafdzfhQgF8dzj5q3eNTCOySYX2sHHo8QvvzU/wrdeBiO0McbNo3B8GLFuqjjCOJs5v3Dsz7QOYZEG3s7eMOeXC9Ab6eKMhjjBoNhZ5K9mnh0jsURPFdK7M/e3HI8agE+/3dAC0NGzyF8NsF5JZRcNQQ1Iw==; s=purelymail2; d=spwhitton.name; v=1; bh=dS2JM37wF5uWGlJ9Jicjd95s992n/yQCteY19WxJ2UA=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=E7mrcR1kE3x+sFXfTw8pxEJuwsNsAhKNU0DdbmY1MkwOwhAdhjv9lQY9Z79Quu7F8SUAMASuZ89jC/PnR8oAa9LjLu7lt/m0VAVcijmHgebLPXOc2dAX2ZdlWJcm9Yw1p7E/MwB4Biu8qs7UwInRXLTFX4KaGcvHsXIYVzcgXHbhgPVl2OVIHMvXg/gjp/lxhH04KYsvVJw8ghg66fiYPve17ZZnnsSX2VbYsYn4qKTg2j59mS8K2yRTVDToXnzW8Sl6F9foAAq3FdoKE+ZBQdq/imjr8CXBW0DN4uygIalH1TcWzvVOtUo7ctDT+kXktFIr+P7wXrNUBTOjG1WEDQ==; s=purelymail2; d=purelymail.com; v=1; bh=dS2JM37wF5uWGlJ9Jicjd95s992n/yQCteY19WxJ2UA=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80006 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1710168392; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 23 Dec 2025 12:26:05 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 985A19404C7; Tue, 23 Dec 2025 12:26:02 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Kristoffer Balintona <krisbalintona@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base In-Reply-To: <CANVbq5=+s-XTU8Rtr3vBjZ19BGGF5sntZHL8d=3b0-keSx1FVA@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> <87sed5ig1u.fsf@HIDDEN> <87o6ntgthw.fsf@HIDDEN> <CANVbq5ndLMU5oOH8kvQdWEjB0v_OZAy2-XZDtfPz0bXRyscFXg@HIDDEN> <87ldivbt1o.fsf@HIDDEN> <CANVbq5=+s-XTU8Rtr3vBjZ19BGGF5sntZHL8d=3b0-keSx1FVA@HIDDEN> Date: Tue, 23 Dec 2025 12:26:02 +0000 Message-ID: <87tsxhe65h.fsf@HIDDEN> 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: 80006 Cc: dmitry@HIDDEN, juri@HIDDEN, 80006 <at> debbugs.gnu.org, Spencer Baugh <sbaugh@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Mon 22 Dec 2025 at 06:15pm -05, Kristoffer Balintona wrote: > With respect to vc-jj, I also like the idea of having a current-branch > backend function: vc-jj does not have a current branch, so having such a > backend function might let VC commands know how to behave with vc-jj > (and other VCSs without a current branch) better. This is a good point. I've pretty much finished the generic code; I'm working on the implementations of the new backend functions for some of our backends in core, now. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 22 Dec 2025 23:15:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 22 18:15:54 2025 Received: from localhost ([127.0.0.1]:50976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXp85-0004Aq-Hr for submit <at> debbugs.gnu.org; Mon, 22 Dec 2025 18:15:54 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:52361) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <krisbalintona@HIDDEN>) id 1vXp82-0004AT-Gf for 80006 <at> debbugs.gnu.org; Mon, 22 Dec 2025 18:15:51 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-38007fa1efbso21961271fa.0 for <80006 <at> debbugs.gnu.org>; Mon, 22 Dec 2025 15:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766445344; x=1767050144; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=GCanN3n7RkQqr7S6fUuhaewk9BFEhARykZLo8CBjqYA=; b=HSU6EfjeqESY3XRx8AcxXHDT1EdlyWhsXLU1kswYPrUjETNZsvwwP3hgS3EL8v6G1N biXe11nwov9YBkiUKoxvX3IyenjjUtlkZ+UPqLZgcJn9Wqarf44cyrFEINglAUfI3BHP 89oikPPkarORCCHcwhrp5pbAN+1lSJuGNFe6KGwAZGA9zjFaLKQ9HzXQEPwa+LTtsgEW se2AMmr4khW3mW2+whJG5juWZXIPQsCyHBkpF7CVsi7PV0Q6GBd1w5au+YaQdT5vm4dE GeQ7a3hPIAy+o6AUYf7BH/ioby1awoC4giRvTNikJlhfemEWqZKuSM3pWpJmrZ5tFUWJ uHKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766445344; x=1767050144; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GCanN3n7RkQqr7S6fUuhaewk9BFEhARykZLo8CBjqYA=; b=jbD2gnjnNnFUNWhXYJT+tvxUlcWFIlBl563epe0bwWaa3939SnmlR7mCMkMhBDVaJP WCGGnkHw94aZoQlxfvod7BvkUz247GoD9DUZE0+SJqDZemr/G2HgBrNWuri7P/6Ndzmi xMx9/7VhCVkdOnj9w4Qc6iI4FQ4nuMlv/7Adl8XIzXBLRCpzaCnHVPU56lWs8xAWxXgf njc8JuyjnpnKw4xhUzYeKlhj1XnzZV6k39bRsqjLfNGVWgnBvJaRKPSGm15vHw8Z8nhb OtV8ryRExhmAEmkBQOBH33VMTKMkucHeEkiBOaEjnYyisIy0eWZO0OgliTA5aSNxaWqZ 1W9g== X-Forwarded-Encrypted: i=1; AJvYcCXKEs5/YW8CcZkqs3hxGOicEQ5ZTTbxwj4atmj/ZofWGlmo+kKRR50IQxQX/i7ACSvHDdf2tQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YygnQ3+aaklgX8N5UrzibFKsf9THnXzAIBrGJ9y3QXEJ+dwSwUF oQrg+iG8xEFHIseQOH1tPk+OjG0jJCNLQ8Oa7RjEpe1DhCA5Brs96ijSlSY8Bcx5yZ5G8q3CKNE FJ6KasamUHqP39u9nCkZPqisUr9np8E1eYg== X-Gm-Gg: AY/fxX6xEt6RwOGQU+FNz7pK+zt8MoIbUr+0mc11VfmaeJ7AVyCBNRElG4uvB1cOUJY 1nhDu8so9qfuJLUk5nADY+C11UJnowYxMPSRH5NYaUu4aQ60gH6+ipphGjfjkgNXOnFcIIg2lGn SCOLMi3WR7/fMi13EYYtydeBxWLK8lD1zzvwaO3+ojmI6mvPJcq1FvL1jX0LJYpE6HNXFMyaNIy FuN/YdmNplV/iB3za1lrL7fUPf8ESYKraYw74z31mSlZ6AEQlWDz13OEzaw8iVReyFHxuQ= X-Google-Smtp-Source: AGHT+IHLkfAeZARTKWuRIAYqWt/iHM1qmhlBMc0fK0rZFbVmHGlr/xwDyv3gduSjP8YBC07+m9EwwgJN3bQBwfOW7WY= X-Received: by 2002:a05:651c:b12:b0:37d:1911:7a45 with SMTP id 38308e7fff4ca-3812169d85emr35595871fa.42.1766445343739; Mon, 22 Dec 2025 15:15:43 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 22 Dec 2025 18:15:41 -0500 Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 22 Dec 2025 18:15:41 -0500 From: Kristoffer Balintona <krisbalintona@HIDDEN> In-Reply-To: <87ldivbt1o.fsf@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> <87sed5ig1u.fsf@HIDDEN> <87o6ntgthw.fsf@HIDDEN> <CANVbq5ndLMU5oOH8kvQdWEjB0v_OZAy2-XZDtfPz0bXRyscFXg@HIDDEN> <87ldivbt1o.fsf@HIDDEN> MIME-Version: 1.0 Date: Mon, 22 Dec 2025 18:15:41 -0500 X-Gm-Features: AQt7F2pHAi4WfVk_2DpeLtXTqNxED8gx9gtVWLJ-jwYb-g3wy71StglkB0bqvW8 Message-ID: <CANVbq5=+s-XTU8Rtr3vBjZ19BGGF5sntZHL8d=3b0-keSx1FVA@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base To: Sean Whitton <spwhitton@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80006 Cc: dmitry@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>, 80006 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Sun, Dec 21 2025, Sean Whitton wrote: > Hello, > > On Sun 21 Dec 2025 at 05:06am -05, Kristoffer Balintona wrote: > >> Hmm... so instead of delegating all the logic to one backend function, >> your idea is to have two backend functions that split that logic: >> - if current-branch returns something meaningful (i.e., the name of the >> active/checked out branch), then we can act on it by pairing it with >> the two regexp defcustoms (falling back to another backend function if >> that doesn't give a definitive answer), >> - and if it doesn't return something meaningful, then we use another >> backend function to carry out the remaining (potentially >> backend-specific) steps for discerning what the current branch is >> (feature or trunk). >> Effectively, with this logic, we have two separate "pathways": one for >> VCSs where there is a checked out branch (e.g., Git) and another for >> VCSs where there isn't a checked out branch (e.g., Jujutsu). >> >> Is that right? I just want to be sure we're on the same page. > > Yes, that's what I mean. > > In most cases it will indeed be two separate pathways, but there will be > some cases where the pathways interact. For example, I am planning to > implement a backend function for Git to classify certain branches as > feature branches based on some git-config(1) options. But that will not > decide the question for most Git branches, and so they will basically > only go down the regexp pathway. After letting your idea sit with me for a bit, I think I'm in support of it. It seems to handle VCSs with or without a checked in/active branch well. With respect to vc-jj, I also like the idea of having a current-branch backend function: vc-jj does not have a current branch, so having such a backend function might let VC commands know how to behave with vc-jj (and other VCSs without a current branch) better. I suppose, then, my only curiosity is whether any other VCS paradigms might feel friction from this approach. Maybe someone could chime in with their experiences. >>> I believe this is functionally equivalent to your scheme but it avoids >>> every single backend that has named branches (almost all of them) having >>> to explicitly call the machinery that looks at the two regexp >>> defcustoms. And it also gives us a current-branch backend function >>> which we'll probably be able to exploit elsewhere. >> >> Yes, I agree that this would be the ideal state of affairs. > > Great. Thank you very much for bringing up vc-jj to help refine the > design. Thanks for the care you took in raising your proposal. -- Kind regards, Kristoffer
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 21 Dec 2025 18:15:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 21 13:15:29 2025 Received: from localhost ([127.0.0.1]:38592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXNxo-0001lp-Sx for submit <at> debbugs.gnu.org; Sun, 21 Dec 2025 13:15:29 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:39304) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vXNxm-0001lS-OP for 80006 <at> debbugs.gnu.org; Sun, 21 Dec 2025 13:15:27 -0500 DKIM-Signature: a=rsa-sha256; b=DOIM+MvWfgptMW9rJZ/wMS1It+gvaY0h3UlHQE6wLNe3ooLrH6+jYy7MfziPs+diiDIBdiPYHdaX3kkh/NM/MFZYflo+5aG6UP2dbHE6LF+RUaulpDY+3FqP5/NXihJdbeHMP3xY8SurRledrQQKETf6fv+bBTNmCjO4SZTNkt3Gq4ehNy5bTbHbuu0j8WEH4O9XYZjRdnAoWb5zTi5peB0cnDQ4+nZ0KiMxo8mUgDqpFqyjxyspyacShgV6rEicttQLZUijbvtpuHtXJZjZ5tH6HjEVVAd7ZgbHdaHXMlpucUpITE5Qp6UjVpDtJlyoJATmxtTMIQVZxFS3PsGdUg==; s=purelymail2; d=spwhitton.name; v=1; bh=85h+OEyx9e5igGEDyN0Bisb5rBSnVypCzSZsaDz77ZA=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=buYQBCXqS17nrHgJAxnYgSDpH3Br2GBpaDUO4EZNIaz2hkH2loQMnZXLyrIrrTf4quM7Q7WixN9No2FPWiUiJ72p7a2+mtL2NCN4eSlW5kGsOPzxhSKN9rsrdORQyLuxT4wJYcKwVvKbG4/m2CgOvg+ypjvFXFbSE2JFNPvvb2Zaf5Q4qVZkzK8RPR2NuSnfdmxoCE1HySkkIdfUxsvNkrfnbzGVivqUUpK8vur58wvT218ZPhsPcMFyOTckJgiBhZZUmKIRnVBtJB9fsC0Tl4JyFlTFhGpkXtQGsh42M2Bbuy9PlrMpCLOqQJvT7tKq4xrZzgczy7+rNVQpfeeCqw==; s=purelymail2; d=purelymail.com; v=1; bh=85h+OEyx9e5igGEDyN0Bisb5rBSnVypCzSZsaDz77ZA=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80006 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 975987676; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 21 Dec 2025 18:15:16 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 050A7940453; Sun, 21 Dec 2025 18:15:16 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Kristoffer Balintona <krisbalintona@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base In-Reply-To: <CANVbq5ndLMU5oOH8kvQdWEjB0v_OZAy2-XZDtfPz0bXRyscFXg@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> <87sed5ig1u.fsf@HIDDEN> <87o6ntgthw.fsf@HIDDEN> <CANVbq5ndLMU5oOH8kvQdWEjB0v_OZAy2-XZDtfPz0bXRyscFXg@HIDDEN> Date: Sun, 21 Dec 2025 18:15:15 +0000 Message-ID: <87ldivbt1o.fsf@HIDDEN> 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: 80006 Cc: dmitry@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>, 80006 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Sun 21 Dec 2025 at 05:06am -05, Kristoffer Balintona wrote: > Hmm... so instead of delegating all the logic to one backend function, > your idea is to have two backend functions that split that logic: > - if current-branch returns something meaningful (i.e., the name of the > active/checked out branch), then we can act on it by pairing it with > the two regexp defcustoms (falling back to another backend function if > that doesn't give a definitive answer), > - and if it doesn't return something meaningful, then we use another > backend function to carry out the remaining (potentially > backend-specific) steps for discerning what the current branch is > (feature or trunk). > Effectively, with this logic, we have two separate "pathways": one for > VCSs where there is a checked out branch (e.g., Git) and another for > VCSs where there isn't a checked out branch (e.g., Jujutsu). > > Is that right? I just want to be sure we're on the same page. Yes, that's what I mean. In most cases it will indeed be two separate pathways, but there will be some cases where the pathways interact. For example, I am planning to implement a backend function for Git to classify certain branches as feature branches based on some git-config(1) options. But that will not decide the question for most Git branches, and so they will basically only go down the regexp pathway. >> I believe this is functionally equivalent to your scheme but it avoids >> every single backend that has named branches (almost all of them) having >> to explicitly call the machinery that looks at the two regexp >> defcustoms. And it also gives us a current-branch backend function >> which we'll probably be able to exploit elsewhere. > > Yes, I agree that this would be the ideal state of affairs. Great. Thank you very much for bringing up vc-jj to help refine the design. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 21 Dec 2025 10:06:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 21 05:06:49 2025 Received: from localhost ([127.0.0.1]:34047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXGKu-0000or-L6 for submit <at> debbugs.gnu.org; Sun, 21 Dec 2025 05:06:48 -0500 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:61841) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <krisbalintona@HIDDEN>) id 1vXGKr-0000oW-Hr for 80006 <at> debbugs.gnu.org; Sun, 21 Dec 2025 05:06:46 -0500 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-37a34702a20so19844141fa.3 for <80006 <at> debbugs.gnu.org>; Sun, 21 Dec 2025 02:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766311599; x=1766916399; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=yiF6rg02yT08996NFc0HqWUt8rkETsPa7yGSW5RfSfI=; b=FGcd0sRCeOgM3lsJaX73adkjBnaQVN0cR7daYwCRE/amerfKbtOKbsziO+JDk6BhYF laXANwl5T5HTAZDPXcAPsCp+nHQ6qirG30X26q7OjBX6moW/0iFWKl80QJi/jgdc7aBs LNdqhckhsutPcpHePhshES/DYOEdoTjGGqo8hP98KZPUJMhqsy1V26oHDxYxX9Cvx476 THUTBgDWCm8XFMPPo54/OJimPZqALUAIzfosw7VNJsEOBz6HUt7EpTlqEUVwIHb7Om6D 0HofBQlug7IP57qk4J8seobq5+96HFt2b0YLxrNbUWJR/NU07TheTFvo5QOXb06NfTn8 dZIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766311599; x=1766916399; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yiF6rg02yT08996NFc0HqWUt8rkETsPa7yGSW5RfSfI=; b=cZ3YJA1u2aZX+OZQxKsg6TTqoGg62pH2l6BkFqfBJGDfAKGGfqP1P6LX5oayco890O X9yxwBuu4Kev5K9fJ3eBSQKPR5syoQWbcsb1BN46fgJZrh/VZmgc24JGlVSWShqvYyOx 3WUe7W4ooPucpRvGlJsvJn73dygNIIgcnA5ZbTFIcI6HlNETg6vCqFvnav7GKpI9cioa MKtDjy8xPjFACCE5tDw4QzfzMQHRYjQolObcHWPJtM8J/OLsD+0C3F6Qhs3+g7PUwgiU LGQON0GvAMYGBUuUTfj66j1qCYa2vkWe+fpmmwFgzmvzaz1ildU3dXBhLWYH+9MbQUIO xB2A== X-Forwarded-Encrypted: i=1; AJvYcCXjS/vtFKyOsMx3U6iQSJMPm3+r/nrFMlhr++M6MUtPEbx6RfHF+0OR4C24g7BMqAHnxfhAPw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzHm6RqHjtE7QAwSuYg4GGogdbU6PJ4zDlVdYe1/Fh1x/Okfdo8 3yrJhPLY2NYjkOO+Q3CI2+qaJ3D4gO79IT1sLeIhVttahW+Ceh0zsl00mqhIAXAHZ8TutqoZPSE a8WADe/pSUP6cduJE0RVgR/wTHKwS4gk= X-Gm-Gg: AY/fxX4OT8XP8DpJcvpTUY0y1MTMnO3Z4i3MinfmSZkk2G6k9pasIdeNOsmhrfit2tb 7I8gKj881MvssafwMYpSJ3fLDJ23e6wjmLboj+ALMWoMQo9aKipyllaG2C8tJO/aNMnTbNhxXek 3Cstn4hK6J1B0LV/uPh8Kr0Mws9y2UeM8hzaOpqx7K2m1AmM98M4GAJcm77+6f6EZqvkIIlsmSE W8pzt0b7sUm7NyOGjdVZi1QOCnJZ64TEwHirBAvXgnf9iayNmTZaPe5y9QSedCA3ZR4NuE= X-Google-Smtp-Source: AGHT+IHQGFdJJwcTA/QWeTRK6xot6+aQ5uSi+VLsZGvYsEIJ/ytJWJYdWhH2EqBQ0CsXqc6behx75HJL14BY2CWwknI= X-Received: by 2002:a2e:8a87:0:b0:37b:9982:5e02 with SMTP id 38308e7fff4ca-38121569a50mr21886211fa.7.1766311598274; Sun, 21 Dec 2025 02:06:38 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Dec 2025 05:06:37 -0500 Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Dec 2025 05:06:37 -0500 From: Kristoffer Balintona <krisbalintona@HIDDEN> In-Reply-To: <87o6ntgthw.fsf@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> <87sed5ig1u.fsf@HIDDEN> <87o6ntgthw.fsf@HIDDEN> MIME-Version: 1.0 Date: Sun, 21 Dec 2025 05:06:37 -0500 X-Gm-Features: AQt7F2qkHSxA4oId3STjsXjIXUx87PI0RmrI27IoKLk7tkxNSiSF35Y3WMCCPhQ Message-ID: <CANVbq5ndLMU5oOH8kvQdWEjB0v_OZAy2-XZDtfPz0bXRyscFXg@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base To: Sean Whitton <spwhitton@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80006 Cc: Spencer Baugh <sbaugh@HIDDEN>, juri@HIDDEN, 80006 <at> debbugs.gnu.org, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Sat, Dec 20 2025, Sean Whitton wrote: > Hello, > > On Sat 20 Dec 2025 at 10:49am GMT, Sean Whitton wrote: > >> It would be great if you could answer the following question: would a >> backend API function to return the name of the current branch be a >> problem for vc-jj? That's a necessary component of the implementation >> of my current approach. But I think I can see a way to do it that >> doesn't involve that, if necessary. > > Actually, I think the following will be VCS-agnostic in your sense, > while following the architectural principle of keeping complexity that > can be up in the generic code, up there, that I've been going for: > > - New current-branch backend function, but the default implementation > always returns nil, which means that there isn't a meaningful answer. > So vc-jj would simply not implement it. > > - To choose the outgoing base, we first call that function. If it > returns nil, we move straight on to asking the backend what kind of > branch this is. > > - If it returns non-nil, we do the comparison against the two regexp > defcustoms. If that comparison yields no definitive answer we ask the > backend what kind of branch this is. Hmm... so instead of delegating all the logic to one backend function, your idea is to have two backend functions that split that logic: - if current-branch returns something meaningful (i.e., the name of the active/checked out branch), then we can act on it by pairing it with the two regexp defcustoms (falling back to another backend function if that doesn't give a definitive answer), - and if it doesn't return something meaningful, then we use another backend function to carry out the remaining (potentially backend-specific) steps for discerning what the current branch is (feature or trunk). Effectively, with this logic, we have two separate "pathways": one for VCSs where there is a checked out branch (e.g., Git) and another for VCSs where there isn't a checked out branch (e.g., Jujutsu). Is that right? I just want to be sure we're on the same page. > I believe this is functionally equivalent to your scheme but it avoids > every single backend that has named branches (almost all of them) having > to explicitly call the machinery that looks at the two regexp > defcustoms. And it also gives us a current-branch backend function > which we'll probably be able to exploit elsewhere. Yes, I agree that this would be the ideal state of affairs. -- Kind regards, Kristoffer
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 20 Dec 2025 13:42:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 08:42:15 2025 Received: from localhost ([127.0.0.1]:49122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWxDq-0006E9-K1 for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 08:42:15 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:52178) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vWxDn-0006Cd-Ow for 80006 <at> debbugs.gnu.org; Sat, 20 Dec 2025 08:42:13 -0500 DKIM-Signature: a=rsa-sha256; b=CIBtX+KRzSAgvNzmybh9uo7DAESitAGfMgstfERoYqKH38sLIEXwaqu+ugpzVOULKOEXeNePHAEogRTUtsaknXDaOiibBJxGAF9gK1Zj/hnZcyBS40Zl2b41WKYo1UVaYczLQyUojlFh8wndNvS7vpVgczHE1IIegcEW1j4sjb5LNcYWlVpUw8C+4GEOEpdzlyYHyKUIsc6n5vMqz10/wbBY0x3swfH6QqgbRloKM8otj9kbxyfMX85TB1KsSlgT9fsmNWHSkl1JpfkKsaFxBdNU29ejjEc87yMhAGpUC878w1KnaXAA/zFwzcxSaEpTbZ2O07dsxpWJ+g4lkqa6Gw==; s=purelymail2; d=spwhitton.name; v=1; bh=USvVRtSX5bMo/NHC/D57Tu0j1nCJmCz/rKhrFSr0STE=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=jq+2IXyFkG0xAl7kR1F51+pTuUfYRWX6Hq7r/VnrSWRGNHjIx5nlhdCtypeoftxVwcHCeh6LhlTAPmqysUAV9h0qXFhOh2QDl2QpQF2zB671aH1T2jiR/F4HSX2FsW+/zEKk7YrAs4rEbEe2pTTEHjYaH2QTcvn2XEZR9EOHT/LzwBLIh6WwemjmvsqnqaQbjIGekMEFYUvE9RDfR/vHG2qfwUCEkOTKaE5c+dm/yx8wqQr6aR5JY4uSIf6UZFs8796s8pz0d70OQjW4fgcWttacSDJLC8eAPtwQGummyR4ae5PtCLwmy7E9PrHNb3UEuDStPRusT6tlK32AqaeONQ==; s=purelymail2; d=purelymail.com; v=1; bh=USvVRtSX5bMo/NHC/D57Tu0j1nCJmCz/rKhrFSr0STE=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80006 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1089215881; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 20 Dec 2025 13:42:04 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 8FFF79407A0; Sat, 20 Dec 2025 13:42:03 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Kristoffer Balintona <krisbalintona@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base In-Reply-To: <87sed5ig1u.fsf@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> <87sed5ig1u.fsf@HIDDEN> Date: Sat, 20 Dec 2025 13:42:03 +0000 Message-ID: <87o6ntgthw.fsf@HIDDEN> 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: 80006 Cc: Spencer Baugh <sbaugh@HIDDEN>, juri@HIDDEN, 80006 <at> debbugs.gnu.org, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Sat 20 Dec 2025 at 10:49am GMT, Sean Whitton wrote: > It would be great if you could answer the following question: would a > backend API function to return the name of the current branch be a > problem for vc-jj? That's a necessary component of the implementation > of my current approach. But I think I can see a way to do it that > doesn't involve that, if necessary. Actually, I think the following will be VCS-agnostic in your sense, while following the architectural principle of keeping complexity that can be up in the generic code, up there, that I've been going for: - New current-branch backend function, but the default implementation always returns nil, which means that there isn't a meaningful answer. So vc-jj would simply not implement it. - To choose the outgoing base, we first call that function. If it returns nil, we move straight on to asking the backend what kind of branch this is. - If it returns non-nil, we do the comparison against the two regexp defcustoms. If that comparison yields no definitive answer we ask the backend what kind of branch this is. I believe this is functionally equivalent to your scheme but it avoids every single backend that has named branches (almost all of them) having to explicitly call the machinery that looks at the two regexp defcustoms. And it also gives us a current-branch backend function which we'll probably be able to exploit elsewhere. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 20 Dec 2025 10:49:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 05:49:50 2025 Received: from localhost ([127.0.0.1]:47257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWuWz-0000E4-PV for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 05:49:50 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:47986) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vWuWw-0000Cp-GO for 80006 <at> debbugs.gnu.org; Sat, 20 Dec 2025 05:49:47 -0500 DKIM-Signature: a=rsa-sha256; b=lPht6blucFS1TitUENUWTHawaHEXSSsxOANBREr22wF++m7KUYjzdD9nzGA2qlGmI2O6vLTRQoh3iIUbZEt0HZdq2deyRh2spllOR3ncX/Dx6EenHagPdmEcp24LhWP/duiNCVGTW3VndKEYUoXuN4GzutroN7rwYBD1j5ORy/T6eR5tABXVKl1QUnwvycqBQxnuemxfkDZBdhnNanRkzuN6g7eiA1gGcBDxk1T06fKrNNroHbJDyl/g1aeMDivAA8dsnl6HlpK4Jtx7Cw2i3lwdA+oFJ8WKzf8DJS4SCVAzpjVdSy6WKO8ARRdXs7e5UnIF/vhDKHwfyL93pPdu1A==; s=purelymail2; d=spwhitton.name; v=1; bh=0Dnz48N4n4ti4x2xdnuH3LstytUPQPFLndH/4J+jyU0=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=dpsjpWg07NIqS6WgCw8QymVAdQpP4q6fHtRM6RKTVmv63Qde/nxrgyfPVCSfak3sCoH2GAM+f+EvFwgAVJIFUK7XqHMtYGNMJFJQNz/+LQKXZUjvNuq2MF8l2Ckvvc0oSJm3Bazmpho7y6paeRh2MsuhlmBk5nt8cTwDkYljPdCLpYSomaC4VAwGOv9tAwoHE1M+HX9vZxhPSrrHWqJ4E3zagzODNgYvLfz8byhMuIvRakm9qk7/97YfmwAFlGfXrmjwee6AppdMF57UTIY4zJV6nYTN7GS6O+wInVfkaM9bDKQHB+qSgBsl/0H/KjwwL1qIxWscjAZIiKuY74Ab2g==; s=purelymail2; d=purelymail.com; v=1; bh=0Dnz48N4n4ti4x2xdnuH3LstytUPQPFLndH/4J+jyU0=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80006 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1089994984; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 20 Dec 2025 10:49:35 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 0ED5F9407A0; Sat, 20 Dec 2025 10:49:33 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Kristoffer Balintona <krisbalintona@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base In-Reply-To: <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> <87o6ny5psn.fsf@HIDDEN> <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN> Date: Sat, 20 Dec 2025 10:49:33 +0000 Message-ID: <87sed5ig1u.fsf@HIDDEN> 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: 80006 Cc: Spencer Baugh <sbaugh@HIDDEN>, juri@HIDDEN, 80006 <at> debbugs.gnu.org, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Sat 20 Dec 2025 at 01:03am -08, Kristoffer Balintona wrote: >> - the backend-generic mechanism to say what kind of branch something is >> by matching its name against regular expressions >> >> (we could still support that, but each backend would have to take care >> to call some function to do the matching, instead of it happening >> transparently to the backends) > > In my view, vc.el should strive to be as VCS-agnostic as possible, and > in my opinion that involves restraining the API to make as few > inferences as possible on behalf of the backend.[1] That is: enforce a > calling convention but let the backend ultimately decide behavior. Thus, > I prefer your parenthetical suggestion, Sean.[2] I don't think it's > unreasonable to add constraints to the VC API/method calling > conventions. As long as these details are sufficiently documented, this > approach grants great flexibility to the backend while still retaining > coherent behavior across VC backends. > > Does that make sense? > > If we have a backend-generic mechanism that uses regexps on branch > names, couldn't we provide that as a default/fallback function that > backends may use it if they wish. Well, this is interesting, because my conception of my non-parenthetical approach is that it is more VCS-agnostic. But I think that in this particular case you might have a point. > Are the features you have in mind possible to implement if the backend > decides the distinction (between trunk and feature branches)? Is it that > you just think it'd be more convenient to not let the entirety of that > determination be up to the backend? I think that for these features VC needs to be able to impose a choice on the backend; specifically, it needs to be able to say "treat the current branch as a trunk". And I'd be inclined to make it possible for VC to impose treating the current branch as a feature branch, too, for future extensibility, even if it's not needed right now. > Footnotes: > [1] In writing this, I have in mind the friction between vc-jj > (https://codeberg.org/emacs-jj-vc/vc-jj.el) and vc.el's API. Part of > that is on account of Jujutsu being an unusual VCS that doesn't > have e.g. branches or a staging area, which isn't vc.el's fault > (since the existence of branches is the norm now). But other times > there is friction because vc.el assumes certain aspects or behaviors > of the VCS. (Not having a staging area isn't unusual -- only Git really has one.) It would be great if you could answer the following question: would a backend API function to return the name of the current branch be a problem for vc-jj? That's a necessary component of the implementation of my current approach. But I think I can see a way to do it that doesn't involve that, if necessary. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.
Received: (at 80006) by debbugs.gnu.org; 20 Dec 2025 09:04:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 04:04:08 2025
Received: from localhost ([127.0.0.1]:46461 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vWssi-0001vd-4Y
for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 04:04:08 -0500
Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:56461)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <krisbalintona@HIDDEN>)
id 1vWssf-0001uf-8E
for 80006 <at> debbugs.gnu.org; Sat, 20 Dec 2025 04:04:06 -0500
Received: by mail-lf1-x12b.google.com with SMTP id
2adb3069b0e04-595825c8eb3so2769384e87.0
for <80006 <at> debbugs.gnu.org>; Sat, 20 Dec 2025 01:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1766221438; x=1766826238; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=Hy+HbuPSQDuDkGtw+AbNLZFFq/5gltaZHLG2VNtj3Y8=;
b=Iy2uOOXSHulq5hop1TbFKoTsw3MTdTHoMP5OCKi7QpE7GH81lEdGMKr4tNwfWvJ0Uz
PB6jZwvjp2S1J2hfEeN2HtHhN9P4lWi4JvCX09XJQQ6jM/Wnb2XXYzvr9R/y99Lv6Kih
NrLhzsj2h3qjbf76aYUXV7flSrrpKLRkw/aFHfuiyNcbcttZ3m3AyIfhcsJbrt5xklQk
93BDO4hkFeBe9mHbbbOuV1YkWo4Vjp6XaznHX8y8Kq66VHBSAXjMCBAezNNmKUPsy1vG
G3EXCCzB3BHWsg9gUf48wHNwhxjZzBvcn5rua6JQ6cWVFWZlmCXb3fpVT+9jJGPloQjc
lIrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1766221438; x=1766826238;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=Hy+HbuPSQDuDkGtw+AbNLZFFq/5gltaZHLG2VNtj3Y8=;
b=ITqrjM43KIdZdPGcgVdM5zTZdsCxzxSbHR4Q4cknd8zhvTkWnRqLTSKyQ5U6jUIhkZ
2+2kFvl2SsfSiQUbvSO/AooCL4xFfirGuvkapuCPPtJXs/ETjYUjYQJD8xoGvXhlh62n
YvUw38U7DtH68gXJwh++YrlwrnKbiNtNAukGHOsmw0OzYs0uGFe1u+pBgPoehJZ7605t
KRjI0zQZ2/jNZUlZrmqY3ze94mGh3j2F1WAM1gZPH3RcbwA0ZdmMXYvPYfHGQv2/k8S8
4UwHNuIAjHfYCF4DkILmoEOC8NmDgSgjfuclNwa2GUw85w0q9F0WhdHhA0Rp/cqzgr25
qevA==
X-Forwarded-Encrypted: i=1;
AJvYcCVGx4OQHVTAAIC4mgmIafzeiQX76QlJ2D7uyHukWoN39JzNwcjT3PtIf8pn9W+SiO3GZBX7UQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzZCLTfj4ibcakNllWGnnA6xSpX+PRyELn87beu5Mz3L9fsSHTN
w7ettuC2IWnczzFxUUptyV+0sAY1fr1AW8QQJms43PXPqkwdvVpkVVJEnpredmayDFImKP40c7w
enPwQDkuzFIPnA3gsckJJOCBSWfWBZ1Q=
X-Gm-Gg: AY/fxX7sxqQlMbQELL/ompveVDJMBAmNiEsyDnzmMBlzUmhr7NoV/KtoKWsdp49hS91
hJtU6WeD0ir3/S5ThGt1m12OKjbolIVjBsDBpvGJUSL/ojoEFuvp2MbE6EiLdwtPQewtymKXFuv
aZ6/K8wi2SS7ndfXoG1VrnPtvrTlwudkyWEwD/jwZqaNHEY25v7v+4YnQAv2Po6elBDFTvnd31W
Td6h5qKC2JMQzLKr0XgRZsG9ffC1dbW2ljEM4nSIWbmOkNmRNW3LaHaD6zgWkiQPvFXb6s=
X-Google-Smtp-Source: AGHT+IE6DZzE3DXFDi+IoBMH9KdNuFoX0Q1nujJtP1x5ygSsolg/Tgl3TPXDrstLPf5KojgceyRh9/ZyE7DtTnI0S4k=
X-Received: by 2002:a2e:a988:0:b0:37b:96e5:dc40 with SMTP id
38308e7fff4ca-38121526f5emr15355031fa.8.1766221438064; Sat, 20 Dec 2025
01:03:58 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Sat, 20 Dec 2025 01:03:56 -0800
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Sat, 20 Dec 2025 01:03:56 -0800
From: Kristoffer Balintona <krisbalintona@HIDDEN>
In-Reply-To: <87o6ny5psn.fsf@HIDDEN>
References: <87cy4ht758.fsf@HIDDEN>
<ier345czmro.fsf@HIDDEN>
<87o6ny5psn.fsf@HIDDEN>
MIME-Version: 1.0
Date: Sat, 20 Dec 2025 01:03:56 -0800
X-Gm-Features: AQt7F2okuFJyBan7qo23WuIR1j5YaiDGqgT3mSGhsMbF1ukKMPqXlUmSyFFrwj4
Message-ID: <CANVbq5mNuhV4++08zUti18AqO4wby-LcB83O+M8TzWKSKsPH_g@HIDDEN>
Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base
To: Sean Whitton <spwhitton@HIDDEN>,
Spencer Baugh <sbaugh@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80006
Cc: dmitry@HIDDEN, juri@HIDDEN, 80006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Tue, Dec 16 2025, Sean Whitton wrote:
> Hello,
>
> On Sun 14 Dec 2025 at 06:06pm -05, Spencer Baugh wrote:
>
>> Why not simply always call this backend function? Delegate the logic of
>> "what is the base revision?" entirely to the backend.
>>
>> This would mean we wouldn't be able to make C-u C-u do anything useful,
>> but that seems fine.
>>
>> Basically, with this kind of backend function where we just call the
>> backend to tell us what the base revision is, I don't see why we would
>> bother distinguish feature vs trunk in vc itself. Just always call the
>> backend function.
>
> Thank you very much for reviewing my long planning message, here.
>
> I considered using a single backend function which just returns the
> appropriate incoming revision or the outgoing base. It's certainly
> nicely simpler. However, there would be a couple of things that we then
> couldn't support:
>
> - as you say, 'C-u C-u C-x v B D' to get an outgoing diff including
> uncommitted changes
>
> - the backend-generic mechanism to say what kind of branch something is
> by matching its name against regular expressions
>
> (we could still support that, but each backend would have to take care
> to call some function to do the matching, instead of it happening
> transparently to the backends)
In my view, vc.el should strive to be as VCS-agnostic as possible, and
in my opinion that involves restraining the API to make as few
inferences as possible on behalf of the backend.[1] That is: enforce a
calling convention but let the backend ultimately decide behavior. Thus,
I prefer your parenthetical suggestion, Sean.[2] I don't think it's
unreasonable to add constraints to the VC API/method calling
conventions. As long as these details are sufficiently documented, this
approach grants great flexibility to the backend while still retaining
coherent behavior across VC backends.
Does that make sense?
If we have a backend-generic mechanism that uses regexps on branch
names, couldn't we provide that as a default/fallback function that
backends may use it if they wish.
> ISTM that both of these features are important. The first one was
> something that was requested back in bug#62940 and it seems useful.
I agree.
> [... 6 lines elided]
>
> Finally, making the distinction between trunk and feature branches
> visible to generic VC code, when we are designing and documenting
> features in terms of that distinction, makes more sense to me than
> leaving it entirely to the backend. It also means that we might be able
> to do other useful things with the distinction in the future.
Are the features you have in mind possible to implement if the backend
decides the distinction (between trunk and feature branches)? Is it that
you just think it'd be more convenient to not let the entirety of that
determination be up to the backend?
Footnotes:
[1] In writing this, I have in mind the friction between vc-jj
(https://codeberg.org/emacs-jj-vc/vc-jj.el) and vc.el's API. Part of
that is on account of Jujutsu being an unusual VCS that doesn't
have e.g. branches or a staging area, which isn't vc.el's fault
(since the existence of branches is the norm now). But other times
there is friction because vc.el assumes certain aspects or behaviors
of the VCS.
[2] Also, the existing use of `vc-use-short-revision' follows the approach
you described in your parenthetical.
--
Kind regards,
Kristoffer
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.Received: (at 80006) by debbugs.gnu.org; 16 Dec 2025 16:56:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 16 11:56:19 2025 Received: from localhost ([127.0.0.1]:57199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vVYLS-0003qQ-OI for submit <at> debbugs.gnu.org; Tue, 16 Dec 2025 11:56:19 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:34162) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vVYLP-0003qB-O0 for 80006 <at> debbugs.gnu.org; Tue, 16 Dec 2025 11:56:16 -0500 DKIM-Signature: a=rsa-sha256; b=eY8ieIDkqVyxmpfOhU7pZW1X74KbpgYbyj/Fd8Nr63YkcsEhuWoQYU+L6LJpvoxCs2NIkT2sjKjljxPZySM0lFtn1OWo2t6832hDueDoze9pug1u3UUzXLIwjy11W3bcEsttYFgRFaTHw/ueNXB4mjsYTUiF4CDSLSm82gXaHiACwDe80rif5TZEffkrcgFmLKyi3T9cTG2u8F9o5fb7YW3xtmAq8lDbq9qUseTaqtxrX3k/4QeWFpaKf6dJO7P72nWQkmWAfkYL61z9jctpp0uIEvQmfw+JpU/Su53ZaHJHXgA7cnTeIYUBT3MEzrpslUwwL4ULR2nrzX7Wd/e7oA==; s=purelymail1; d=spwhitton.name; v=1; bh=NMOwVF8rSHbRkm6si/xJ1TAhjd8NiSaotHunc0MkSgc=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=fiEDAqcwdfkDO/jdjCosh3XLc+Cnz7rejLNojF+fZ+vCQaQf47h6jgSLQ7iicmtVM/aQ+TQ5vBd48iKMQgGnpR3TLDUEoEEb6NWt6Be+olVcCzRvENIfuoRfb5QaP2ssTGXhTL9TEiD88GggSwUTFEX3BNvyuY87ORwqZ6XbXJ0k+cMmnziZrdaOj9b3JkNvSnWMPtkj/i9DAZhxcTLHuT2X7JWglHlqxt/uqq/qSK1m3jYgi0Fd7auRYIxejO9Xs7gLyoHFLopAJwZCbP7fHoSE822t0UomIVaN627B/dnNd01q5W7br3SM6AoBQe6JSy9Qk2M82OS8/gnFoQDzqg==; s=purelymail1; d=purelymail.com; v=1; bh=NMOwVF8rSHbRkm6si/xJ1TAhjd8NiSaotHunc0MkSgc=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80006 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1015090665; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 16 Dec 2025 16:56:09 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id C1E4B94040D; Tue, 16 Dec 2025 16:56:08 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base In-Reply-To: <ier345czmro.fsf@HIDDEN> References: <87cy4ht758.fsf@HIDDEN> <ier345czmro.fsf@HIDDEN> Date: Tue, 16 Dec 2025 16:56:08 +0000 Message-ID: <87o6ny5psn.fsf@HIDDEN> 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: 80006 Cc: dmitry@HIDDEN, 80006 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Sun 14 Dec 2025 at 06:06pm -05, Spencer Baugh wrote: > Why not simply always call this backend function? Delegate the logic of > "what is the base revision?" entirely to the backend. > > This would mean we wouldn't be able to make C-u C-u do anything useful, > but that seems fine. > > Basically, with this kind of backend function where we just call the > backend to tell us what the base revision is, I don't see why we would > bother distinguish feature vs trunk in vc itself. Just always call the > backend function. Thank you very much for reviewing my long planning message, here. I considered using a single backend function which just returns the appropriate incoming revision or the outgoing base. It's certainly nicely simpler. However, there would be a couple of things that we then couldn't support: - as you say, 'C-u C-u C-x v B D' to get an outgoing diff including uncommitted changes - the backend-generic mechanism to say what kind of branch something is by matching its name against regular expressions (we could still support that, but each backend would have to take care to call some function to do the matching, instead of it happening transparently to the backends) ISTM that both of these features are important. The first one was something that was requested back in bug#62940 and it seems useful. The second one lets someone configure their repository such that they can use the outgoing base commands on any branch and get a sensible answer. Otherwise, if you know your backend can't unambiguously identify trunk branches (which will be by far the most common case), you can't use the outgoing base commands whenever you're on a trunk branch, which might be inconvenient. Finally, making the distinction between trunk and feature branches visible to generic VC code, when we are designing and documenting features in terms of that distinction, makes more sense to me than leaving it entirely to the backend. It also means that we might be able to do other useful things with the distinction in the future. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.
Received: (at 80006) by debbugs.gnu.org; 14 Dec 2025 23:06:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 14 18:06:46 2025
Received: from localhost ([127.0.0.1]:58896 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vUvAs-0003HB-1z
for submit <at> debbugs.gnu.org; Sun, 14 Dec 2025 18:06:46 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:51805)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vUvAn-0003Ge-Ti
for 80006 <at> debbugs.gnu.org; Sun, 14 Dec 2025 18:06:44 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: Sean Whitton <spwhitton@HIDDEN>
Subject: Re: bug#80006: 31.0.50; Automatically choosing the VC outgoing base
In-Reply-To: <87cy4ht758.fsf@HIDDEN> (Sean Whitton's message
of "Sun, 14 Dec 2025 15:28:19 +0000")
References: <87cy4ht758.fsf@HIDDEN>
Date: Sun, 14 Dec 2025 18:06:35 -0500
Message-ID: <ier345czmro.fsf@HIDDEN>
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=1765753596;
bh=iO1+7GGkYlzidABR0wfqntdSg8Mj8T2XmW1bdGAsTwo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=rKdbzUrLBQKHX1Vcs7DucizSyV/yldm6gopg2SQzaQ+P+zNhs++CfZe3Ag4dlzEpK
TbP7uz97sy/NbWIrZCBx9Lr2L2dcs3BfCiaNtKiTYJgtXdDJCzq0GHDfbvCpeaxgvS
rkZB4qLmzMx4CietdS0ixXXYkt9na/lyWazd0A4GY4pCs2rLe7K3DyoV97Vskjibm0
u5Uqz+L03HhuGw2CmQeTpCYozwIjzN5lwBuGzb/Pnx1TB3TaxBLfhx+LYJPcaEPx1A
+oKvVtN/4xx6WbsNkUt1R9XB4PMFR4In9brMiDOnspcof9x+Nyft1GD8If/uyh4lMw
55tTqzeVaPMng==
X-Spam-Score: -1.7 (-)
X-Debbugs-Envelope-To: 80006
Cc: 80006 <at> debbugs.gnu.org, juri@HIDDEN, dmitry@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.7 (--)
Sean Whitton <spwhitton@HIDDEN> writes:
> X-debbugs-cc: sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN
>
> I previously annotated the code for 'C-x v B =' and 'C-x v B D' with:
>
>> For the following two commands, the default meaning for
>> UPSTREAM-LOCATION may become dependent on whether we are on a
>> shorter-lived or longer-lived ("trunk") branch. If we are on the
>> trunk then it will always be the place `vc-push' would push to. If we
>> are on a shorter-lived branch, it may instead become the remote trunk
>> branch from which the shorter-lived branch was branched. That way you
>> can use these commands to get a summary of all unmerged work
>> outstanding on the short-lived branch.
>>
>> The obstacle to doing this is that VC lacks any distinction between
>> shorter-lived and trunk branches. But we all work with both of these,
>> for almost any VCS workflow. E.g. modern workflows which eschew
>> traditional feature branches still have a long-lived trunk plus
>> shorter-lived local branches for merge requests or patch series.
>
> I now think I have an adequate plan to address this.
>
> BACKGROUND
> ==========
>
> For the 'C-x v B' commands to be convenient, they need to automatically
> choose an outgoing base, and the choice needs to be correct often enough
> that people feel it's worth their time invoking the commands.
>
> Primarily that means: if I'm on a feature branch, the 'C-x v B' commands
> need to correctly guess what branch my work on this branch will
> eventually be merged back into.
>
> Secondarily, it means that if I'm on a trunk branch, it needs to be easy
> to use 'C-x v B =' and 'C-x v B D' as versions of 'C-x v O =' and
> 'C-x v O D' that include uncommitted changes.
>
> If we know for sure whether a branch is a trunk or a feature branch,
> then it relatively easy to guess the correct outgoing base. For an
> older VCS where there is one trunk and it's always called 'trunk', this
> is easy. But for newer VCS, trunk branches are not privileged in this
> way. It just depends on how they are used, which they are.
>
> So, we have to make our guess without knowing for sure which kind of
> branch this is. And, to be clear, it's only worth making a guess if it
> is a good guess. Otherwise people won't bother using the 'C-x v B'
> commands much. This is the unresolved problem.
>
> STRATEGY
> ========
>
> I propose to generally assume that we're on a feature branch when the
> user invokes one of the 'C-x v B' commands, because these commands are
> primarily useful on feature branches. So then instead of trying to
> answer "is this a trunk or a feature branch?" we have to answer "*were*
> this to be a feature branch, what would its outgoing base probably be?",
> which is much easier.
>
> To satisfy the use case of versions of the outgoing diff commands which
> include uncommitted changes, I propose to use a double prefix argument.
> So 'C-u C-u' requests inverting the general assumption: 'C-u C-u' means
> to assume that we're on a trunk branch.
>
> In addition, we can have some mechanisms that are able to say that a
> branch is definitely a trunk branch or definitely a feature branch.
> These would override the general assumption. The idea is that these
> mechanisms would return either "def a trunk", "def a feature", "don't
> know for sure". So either they know for sure and we follow that, or we
> fall back to our general assumption and the 'C-u C-u' override.
>
> MAKING THE CHOICE
> =================
>
> Here is a summary of the algorithm for choosing the UPSTREAM-LOCATION I
> propose:
>
> 1. With a single C-u, we prompt for the upstream, as we do at present
> for all these commands.
>
> 2. With a C-u C-u prefix argument, assume it's a trunk branch, and skip
> to step (6) below.
>
> 3. Check the branch name against two defcustoms, which each specify a
> list of regular expressions matching branches that are definitely
> trunks and that are definitely feature branches.
>
> If an entry in one of the defcustoms does not contain any regular
> expression metacharacters, then it's a literal name of a branch
> anchored at both ends.
>
> The default value for the list of regular expressions matching
> branches that are assumed to be trunks would be '("master" "main"
> "trunk" "default") and the default value for the defcustom matching
> branches that are assumed to be feature branches would be nil.
>
> Although the usual names of trunks is VCS-specific, I propose making
> these global defcustoms, for simplicity. I don't think there's much
> benefit to only looking for "master" and "main" if it's a Git
> repository, for example.
>
> For repositories with a branch naming scheme, these defcustoms can be
> set as directory-local variables. For example, for emacs.git we can
> add "\\`emacs-[0-9]+\\'" to the defcustom for trunk branches and
> "\\`\\(?:feature\\|scratch\\)/" to the defcustom for feature branches
> (and some others possibly).
>
> I think we would want some way to negate the whole value,
> e.g. pushing `not' to the front of the list. I don't think we need
> full and/or/not handling. Some way to specify "the negation of the
> other defcustom" would be good too, so that you could specify "any
> branch not a trunk branch, according to the other defcustom, is a
> feature branch". (Though I do not think that should be the default.
> The default should be that we don't know which type it is.)
>
> If the branch name matches both defcustoms, I'd be in favour of
> signalling an error, for now, to avoid locking in one priority order.
>
> If we move on to the next step that means the defcustom mechanism is
> saying "don't know for sure".
>
> 4. Ask the backend whether it thinks the branch is a trunk or feature
> branch. This would be an optional backend function returning
> `trunk', `feature' or nil (for "not sure"). For CVS I believe we can
> return `trunk' if it's the branch named `trunk', and `feature'
> otherwise. For Git, we can return `feature' for a branch that has an
> upstream that has a different name and a pushRemote of the same name,
> or some similar heuristic. A third party backend could hook in here,
> too.
>
> 5. If (3) and (4) both yield "don't know", assume it's a feature branch,
> because the user has invoked one of the 'C-x v B' commands, which
> usually imply wanting to work with a feature branch.
>
> 6. We now have a determination of whether this is a trunk or feature
> branch. We now need an appropriate incoming revision. If it's a
> trunk branch, we can just proceed as all the existing commands
> already do: use a nil UPSTREAM-LOCATION to get the incoming revision
> for the place to which vc-push would push.
>
> If it's a feature branch, we call into the backend again, using a
> different API call, to request an incoming revision for this branch
> considered as a feature branch. Generally this will be the incoming
> revision for the branch from which this feature branch was branched
> and to which it will later be merged back into. I think searching
> backwards for a branch point is the general way to do this. An
> alternative might be to look at what has been merged into us. We
> might require the other branch to be one that exists as a local
> branch, if the VCS distinguishes between local and remote branches.
Why not simply always call this backend function? Delegate the logic of
"what is the base revision?" entirely to the backend.
This would mean we wouldn't be able to make C-u C-u do anything useful,
but that seems fine.
Basically, with this kind of backend function where we just call the
backend to tell us what the base revision is, I don't see why we would
bother distinguish feature vs trunk in vc itself. Just always call the
backend function.
>
> Finally we obtain the outgoing base by finding the merge base of the
> incoming revision we just obtained and the working revision.
>
> ALTERNATIVE C-u C-u
> ===================
>
> Instead of C-u C-u meaning to assume a trunk branch, it could mean to
> invert the automatic determination. So, when we get to (5) above, if
> the user had typed C-u C-u, we then invert our determination.
>
> I think this introduces significant cognitive overhead and is not useful
> enough. The general assumption is that we are on a feature branch, not
> the other way around, so what's more important is being able to invert
> that general assumption, not invert the whole algorithm.
I agree, I don't think that's very useful.
> NEW COMMANDS
> ============
>
> The above will enhance the existing 'C-x v B =' and 'C-x v B D'.
> I intend to fill out the command set by adding 'C-x v B l'
> and 'C-x v B L', which will work as you would expect.
>
> A more exciting command is 'C-x v B +'. Where 'C-x v +' always pulls
> from the same place to which vc-push pushes, 'C-x v B +' means to pull
> from the true upstream of a feature branch, i.e., the branch from which
> this feature branch was originally started.
>
> So for example if you were on feature/igc, 'C-x v B +' would fetch and
> merge origin/master into feature/igc.
>
> If the VCS is configured to do rebases instead of merges, 'C-x v B +'
> would mean to fetch the trunk and rebase your feature branch onto it.
> This would be a common operation in a typical PR/MR workflow with modern
> web forges. I'll discuss this example in the docs.
> (To make this work with Git may or may not require explicitly
> configuring a pushRemote; I'll have to see about that.)
All seems reasonable.
bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 14 Dec 2025 15:28:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 14 10:28:54 2025
Received: from localhost ([127.0.0.1]:54128 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vUo1l-0000By-Da
for submit <at> debbugs.gnu.org; Sun, 14 Dec 2025 10:28:54 -0500
Received: from lists.gnu.org ([2001:470:142::17]:55268)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>)
id 1vUo1h-0000BZ-Jc
for submit <at> debbugs.gnu.org; Sun, 14 Dec 2025 10:28:50 -0500
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 <spwhitton@HIDDEN>)
id 1vUo1Z-0001XF-5H
for bug-gnu-emacs@HIDDEN; Sun, 14 Dec 2025 10:28:42 -0500
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 <spwhitton@HIDDEN>)
id 1vUo1W-0000Jh-8h
for bug-gnu-emacs@HIDDEN; Sun, 14 Dec 2025 10:28:40 -0500
DKIM-Signature: a=rsa-sha256;
b=Vi1p2VMYNN0cGJHNhBLlVtjTcM4UH/9wuJukonNq3u0siEXEX3+FJAIVjmoWtvNz0l8ClwHZNvtkbTjbqqnhzyuR0M9bbaX7j5iBMLl31iML1XdQXxZAmCiub7A3d6uZGRxGoytDSEH8xH+Qt6YdHpXlBbgh6SkC97cWt+uQ2qCnYM4HaRT/WZBO6Ja4idbNR/2GtnfN1RtGOYvrflWYupTdrC4di2uiX1G/j92XdDG1Cun2zkkiILHgCZTJNdVJYUOS4sAD9jKrrYUIq4yY7xgdWOKoueZsUgTGl2xrMwvsSbzJnzPz4Fkh3cq9kflqkiDO3OEo9fYkou56VBZCDw==;
s=purelymail1; d=spwhitton.name; v=1;
bh=AKO2fjC9TmZi5u5UpcF9gfz5MAn+hZBs+3kWGq/XrN0=;
h=Received:Received:From:To:Subject:Date;
DKIM-Signature: a=rsa-sha256;
b=ioOhXhZJgFQf2vzpjOxg/d65SOhqrdZSdKFDcbUn6JLcvOizFpRb/9LSktty6oY+EoV7dIU5ZP7WvNAT92n+cQ2lK+MfP5m0HMRTjzA7LXt5Voa7v8Oge02oqkmHPRyn9/8PPdXo/DsMkLydru3AQFsQJOT+dpfvLQyEWVuzZEr+eoSRcJhDhkaPvKvJNseuTViJysQo+iFnjHiiZ8MtRzirb/rbu8dC8yqIjTQPbZXdmxN4z51HTRQwWLmJw9oBB7YSf55faeO21Tu63h6tAO6Rt4CUns3MCwYEz/KFse2hiEkgCRhWEiqsKHHWULKAzKyEzAVz7hZeP+z7zqCcig==;
s=purelymail1; d=purelymail.com; v=1;
bh=AKO2fjC9TmZi5u5UpcF9gfz5MAn+hZBs+3kWGq/XrN0=;
h=Feedback-ID:Received:Received:From:To:Subject:Date;
Feedback-ID: 20115:3760:null:purelymail
X-Pm-Original-To: bug-gnu-emacs@HIDDEN
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -796238214
for <bug-gnu-emacs@HIDDEN>
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
Sun, 14 Dec 2025 15:28:20 +0000 (UTC)
Received: by zephyr.silentflame.com (Postfix, from userid 1000)
id 613C19402F8; Sun, 14 Dec 2025 15:28:19 +0000 (GMT)
From: Sean Whitton <spwhitton@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; Automatically choosing the VC outgoing base
Date: Sun, 14 Dec 2025 15:28:19 +0000
Message-ID: <87cy4ht758.fsf@HIDDEN>
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@HIDDEN; helo=sendmail.purelymail.com
X-Spam_score_int: -30
X-Spam_score: -3.1
X-Spam_bar: ---
X-Spam_report: (-3.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=-1,
RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
RCVD_IN_VALIDITY_RPBL_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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
X-debbugs-cc: sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN
I previously annotated the code for 'C-x v B =' and 'C-x v B D' with:
> For the following two commands, the default meaning for
> UPSTREAM-LOCATION may become dependent on whether we are on a
> shorter-lived or longer-lived ("trunk") branch. If we are on the
> trunk then it will always be the place `vc-push' would push to. If we
> are on a shorter-lived branch, it may instead become the remote trunk
> branch from which the shorter-lived branch was branched. That way you
> can use these commands to get a summary of all unmerged work
> outstanding on the short-lived branch.
>
> The obstacle to doing this is that VC lacks any distinction between
> shorter-lived and trunk branches. But we all work with both of these,
> for almost any VCS workflow. E.g. modern workflows which eschew
> traditional feature branches still have a long-lived trunk plus
> shorter-lived local branches for merge requests or patch series.
I now think I have an adequate plan to address this.
BACKGROUND
==========
For the 'C-x v B' commands to be convenient, they need to automatically
choose an outgoing base, and the choice needs to be correct often enough
that people feel it's worth their time invoking the commands.
Primarily that means: if I'm on a feature branch, the 'C-x v B' commands
need to correctly guess what branch my work on this branch will
eventually be merged back into.
Secondarily, it means that if I'm on a trunk branch, it needs to be easy
to use 'C-x v B =' and 'C-x v B D' as versions of 'C-x v O =' and
'C-x v O D' that include uncommitted changes.
If we know for sure whether a branch is a trunk or a feature branch,
then it relatively easy to guess the correct outgoing base. For an
older VCS where there is one trunk and it's always called 'trunk', this
is easy. But for newer VCS, trunk branches are not privileged in this
way. It just depends on how they are used, which they are.
So, we have to make our guess without knowing for sure which kind of
branch this is. And, to be clear, it's only worth making a guess if it
is a good guess. Otherwise people won't bother using the 'C-x v B'
commands much. This is the unresolved problem.
STRATEGY
========
I propose to generally assume that we're on a feature branch when the
user invokes one of the 'C-x v B' commands, because these commands are
primarily useful on feature branches. So then instead of trying to
answer "is this a trunk or a feature branch?" we have to answer "*were*
this to be a feature branch, what would its outgoing base probably be?",
which is much easier.
To satisfy the use case of versions of the outgoing diff commands which
include uncommitted changes, I propose to use a double prefix argument.
So 'C-u C-u' requests inverting the general assumption: 'C-u C-u' means
to assume that we're on a trunk branch.
In addition, we can have some mechanisms that are able to say that a
branch is definitely a trunk branch or definitely a feature branch.
These would override the general assumption. The idea is that these
mechanisms would return either "def a trunk", "def a feature", "don't
know for sure". So either they know for sure and we follow that, or we
fall back to our general assumption and the 'C-u C-u' override.
MAKING THE CHOICE
=================
Here is a summary of the algorithm for choosing the UPSTREAM-LOCATION I
propose:
1. With a single C-u, we prompt for the upstream, as we do at present
for all these commands.
2. With a C-u C-u prefix argument, assume it's a trunk branch, and skip
to step (6) below.
3. Check the branch name against two defcustoms, which each specify a
list of regular expressions matching branches that are definitely
trunks and that are definitely feature branches.
If an entry in one of the defcustoms does not contain any regular
expression metacharacters, then it's a literal name of a branch
anchored at both ends.
The default value for the list of regular expressions matching
branches that are assumed to be trunks would be '("master" "main"
"trunk" "default") and the default value for the defcustom matching
branches that are assumed to be feature branches would be nil.
Although the usual names of trunks is VCS-specific, I propose making
these global defcustoms, for simplicity. I don't think there's much
benefit to only looking for "master" and "main" if it's a Git
repository, for example.
For repositories with a branch naming scheme, these defcustoms can be
set as directory-local variables. For example, for emacs.git we can
add "\\`emacs-[0-9]+\\'" to the defcustom for trunk branches and
"\\`\\(?:feature\\|scratch\\)/" to the defcustom for feature branches
(and some others possibly).
I think we would want some way to negate the whole value,
e.g. pushing `not' to the front of the list. I don't think we need
full and/or/not handling. Some way to specify "the negation of the
other defcustom" would be good too, so that you could specify "any
branch not a trunk branch, according to the other defcustom, is a
feature branch". (Though I do not think that should be the default.
The default should be that we don't know which type it is.)
If the branch name matches both defcustoms, I'd be in favour of
signalling an error, for now, to avoid locking in one priority order.
If we move on to the next step that means the defcustom mechanism is
saying "don't know for sure".
4. Ask the backend whether it thinks the branch is a trunk or feature
branch. This would be an optional backend function returning
`trunk', `feature' or nil (for "not sure"). For CVS I believe we can
return `trunk' if it's the branch named `trunk', and `feature'
otherwise. For Git, we can return `feature' for a branch that has an
upstream that has a different name and a pushRemote of the same name,
or some similar heuristic. A third party backend could hook in here,
too.
5. If (3) and (4) both yield "don't know", assume it's a feature branch,
because the user has invoked one of the 'C-x v B' commands, which
usually imply wanting to work with a feature branch.
6. We now have a determination of whether this is a trunk or feature
branch. We now need an appropriate incoming revision. If it's a
trunk branch, we can just proceed as all the existing commands
already do: use a nil UPSTREAM-LOCATION to get the incoming revision
for the place to which vc-push would push.
If it's a feature branch, we call into the backend again, using a
different API call, to request an incoming revision for this branch
considered as a feature branch. Generally this will be the incoming
revision for the branch from which this feature branch was branched
and to which it will later be merged back into. I think searching
backwards for a branch point is the general way to do this. An
alternative might be to look at what has been merged into us. We
might require the other branch to be one that exists as a local
branch, if the VCS distinguishes between local and remote branches.
Finally we obtain the outgoing base by finding the merge base of the
incoming revision we just obtained and the working revision.
ALTERNATIVE C-u C-u
===================
Instead of C-u C-u meaning to assume a trunk branch, it could mean to
invert the automatic determination. So, when we get to (5) above, if
the user had typed C-u C-u, we then invert our determination.
I think this introduces significant cognitive overhead and is not useful
enough. The general assumption is that we are on a feature branch, not
the other way around, so what's more important is being able to invert
that general assumption, not invert the whole algorithm.
NEW COMMANDS
============
The above will enhance the existing 'C-x v B =' and 'C-x v B D'.
I intend to fill out the command set by adding 'C-x v B l'
and 'C-x v B L', which will work as you would expect.
A more exciting command is 'C-x v B +'. Where 'C-x v +' always pulls
from the same place to which vc-push pushes, 'C-x v B +' means to pull
from the true upstream of a feature branch, i.e., the branch from which
this feature branch was originally started.
So for example if you were on feature/igc, 'C-x v B +' would fetch and
merge origin/master into feature/igc.
If the VCS is configured to do rebases instead of merges, 'C-x v B +'
would mean to fetch the trunk and rebase your feature branch onto it.
This would be a common operation in a typical PR/MR workflow with modern
web forges. I'll discuss this example in the docs.
(To make this work with Git may or may not require explicitly
configuring a pushRemote; I'll have to see about that.)
--
Sean Whitton
Sean Whitton <spwhitton@HIDDEN>:sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80006; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.