From unknown Sun Jul 20 15:37:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79024 <79024@debbugs.gnu.org> To: bug#79024 <79024@debbugs.gnu.org> Subject: Status: 31.0.50; Multiple working trees support for VC Reply-To: bug#79024 <79024@debbugs.gnu.org> Date: Sun, 20 Jul 2025 22:37:49 +0000 retitle 79024 31.0.50; Multiple working trees support for VC reassign 79024 emacs submitter 79024 Sean Whitton severity 79024 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 07:50:56 2025 Received: (at submit) by debbugs.gnu.org; 15 Jul 2025 11:50:56 +0000 Received: from localhost ([127.0.0.1]:40706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubeBU-0000tO-3n for submit@debbugs.gnu.org; Tue, 15 Jul 2025 07:50:56 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45436) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubeBQ-0000t2-0f for submit@debbugs.gnu.org; Tue, 15 Jul 2025 07:50:53 -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 1ubeBG-00080j-MZ for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2025 07:50:44 -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 1ubeBC-0003wQ-K6 for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2025 07:50:42 -0400 DKIM-Signature: a=rsa-sha256; b=JUxBzZ+IREulnJXnjqmTspujnX7S3+g+sY5E2vYYAm3xAiDXBjD6JpxofA+gmaTGJfV6rXk2jBiPOnbURscXEZVckFtriRqsNO5erC0LiMIhvsKuCdEHv/k0l15riwH+cAXI1/dzWg549+TO7NXu2bo70gcGRYKaoes/A9nDqjaxlttCWDIe5mUsfnJN4m+nYAMvBAFNSMd0ugc6XJUeLfQewZaO4yWlSLwcB8bvEb3xxkBZ41gzeupOrmVcg7JIADCmnUVq5hCO/uzdenZJWkARX+5iXdxitFRmgQzoXooPp5XZ4biyw3wwuW7ThpitsZWJhSazI14CR9DzF6zBsA==; s=purelymail3; d=spwhitton.name; v=1; bh=DQAiSG77lwa2quMwMso1EyEBqjXJu/h7GDBQzpkmSus=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=rHhDpLmpEUWUzgovcqJ+rgxJSqrDaERp3u9lyoH7NE4L/NbfvOVRAwXq6BV/QKHhNM65d4BrVEf87gnK9PdPCJiJDj/uU9EkDRWgMc01QnuAlWlIoM52CQJviGMz8AZVRpVJ1rPkA8FP+FMrWF6PisSebcmQx0GGEs5/o86DXWZx0ztAV5Ra5aNZCMi1HNSpBshfsSPQTWGwV9AEucSVNhaas3nVU73qZGWX/z+hid8W201iIlymg6TGV6NnKfAPHu0WdZ0AVTrafNnMofkeCcDCN9ChLac8EshECwZYNtYhpuo6+pmpN2YyFyZQ80FcGs0j6+b0BVLOcdTBw5xQdw==; s=purelymail3; d=purelymail.com; v=1; bh=DQAiSG77lwa2quMwMso1EyEBqjXJu/h7GDBQzpkmSus=; 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 -212229368 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 15 Jul 2025 11:50:34 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 1354A941B63; Tue, 15 Jul 2025 12:50:34 +0100 (BST) From: Sean Whitton To: bug-gnu-emacs@gnu.org Subject: 31.0.50; Multiple working trees support for VC Date: Tue, 15 Jul 2025 12:50:34 +0100 Message-ID: <87v7nt4qr9.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: sbaugh@janestreet.com, dmitry@gutov.dev Hello, I would like to add support for multiple working trees to VC. This is 'git worktree' for Git and 'hg share' for Mercurial. It may or may not map onto trunk/ vs. branch/ in SVN; see below. TERMINOLOGY VC's documentation consistently uses "working tree" to refer to what we often also call the "working directory", "clone", "checkout". I think that we can introduce the idea of "other working trees" and commands that operate on them. I don't believe we need to distinguish between primary and secondary working trees, which is a VCS-specific concept. If a Git user tries to delete the primary worktree from a secondary worktree, for example, it's just an error, signalled by the relevant backend-specific function. These commands would probably be meaningful only for changeset-based VCS, not file-based VCS. COMMANDS - C-x v w c: Add a new working tree. The user must specify what branch, revision or tag to check out there. Probably the prompting should be as similar as possible to C-x v r and/or C-x v b s (which we might want to improve and/or unify first). - C-x v w w: Switch to another working tree. This is a contextual command. When used in a file-visiting or dired buffer, it means visit that same file name under one of the other working trees. E.g. if you have worktrees for the Emacs master and release branches, you can use it to hop between vc.el on master and vc.el on emacs-30. In *vc-dir* it means to switch to *vc-dir* for the other worktree. Each working tree is already a separate project.el project, which is what we want. + If we keep the list of other working trees sorted by recency, then C-x v w w RET would allow you to switch back and forth between (the same file name in) your two most recently used working trees. - C-x v w s: A wrapper around C-x p p but with selection limited to other working trees of this project. - C-x v w x: Delete a working tree. - C-x v w R: Relocate a working tree. Move or rename it, updating VC and project.el metadata as appropriate. BACKEND FUNCTIONS - other-working-trees: Return a list of all other working trees. - add-working-tree, delete-working-tree, move-working-tree. SVN BRANCHES Adding a new working tree is the same as creating a new branch, I think? I think there are two ways we could go here: 1. Decide that SVN does not support other working trees in the sense of these new commands, such that they are no-ops. 2. Make the new commands effectively synonyms of existing branch-related commands for SVN. QUESTIONS - Are there other things that we might want to support that wouldn't be covered by this API? - Does project.el need to know about these relationships between trees, or do we leave it all up to VC? I think the latter. I.e., from project.el's point of view, each working tree is its own project. - What shall we do with CVS/SVN branches? I've made two suggestions. - How are the bindings I've suggested? Intuitive enough? Thank you in advance for any feedback. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 17 13:24:44 2025 Received: (at 79024) by debbugs.gnu.org; 17 Jul 2025 17:24:45 +0000 Received: from localhost ([127.0.0.1]:56254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucSLc-0006PM-7W for submit@debbugs.gnu.org; Thu, 17 Jul 2025 13:24:44 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41241) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucSLZ-0006Ow-Qb for 79024@debbugs.gnu.org; Thu, 17 Jul 2025 13:24:43 -0400 From: Spencer Baugh To: Sean Whitton Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC In-Reply-To: <87v7nt4qr9.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Tue, 15 Jul 2025 12:50:34 +0100") References: <87v7nt4qr9.fsf@zephyr.silentflame.com> Date: Thu, 17 Jul 2025 13:24:36 -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=1752773076; bh=giNZc/h1JxF8iyVvbb/47fr7RDPEPOl494sp1pHAbqw=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=VPp41Ae/b08WYSrJTI5xFn26s7OchCSY+7rIRQWaAEU82xSXiHFSaftzIFCyJwcjW NBJ5q15BaAB4+NXdzFmmizOK7SfSCjQg96MSRUFUuhOsUWaKBbcGgy9RSdr8/kBBCo QrIvlj0HiXPum+hvFCqb6WEAmlM3udcuA/DVlfwEMpTmcL4Lby88NJY9OfhdsptvxO GPNplUdJzdDVEZEX3Hcx37MXx+04Z/lHpSzWF3ZmOUrOGmU6N1DoYQrXXfgJU0uC71 4f6fAdJhP7KLyR5e68AX6vLIFop83tJj+/bu4LTRUjK7PbE2XPMj1kQf5UkC5CHJqR KJb/qXYH6dNrA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79024 Cc: 79024@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: -3.3 (---) Sean Whitton writes: > X-debbugs-cc: sbaugh@janestreet.com, dmitry@gutov.dev > > Hello, > > I would like to add support for multiple working trees to VC. This is > 'git worktree' for Git and 'hg share' for Mercurial. It may or may not > map onto trunk/ vs. branch/ in SVN; see below. Exciting! > TERMINOLOGY > > VC's documentation consistently uses "working tree" to refer to what we > often also call the "working directory", "clone", "checkout". > > I think that we can introduce the idea of "other working trees" and > commands that operate on them. I don't believe we need to distinguish > between primary and secondary working trees, which is a VCS-specific > concept. If a Git user tries to delete the primary worktree from a > secondary worktree, for example, it's just an error, signalled by the > relevant backend-specific function. Yes, that sounds good to me. This is ideal because this already matches up well with the "worktree" terminology in Git. I briefly considered proposing that command names use "vc-worktree" instead of "vc-working-tree", but I actually think "vc-working-tree" is better than "vc-worktree" because tab completion will expand "vc-w-t" unambiguously to vc-working-tree but "vc-w" can't expand to vc-worktree. > These commands would probably be meaningful only for changeset-based > VCS, not file-based VCS. > > COMMANDS > > - C-x v w c: Add a new working tree. > > The user must specify what branch, revision or tag to check out there. > Probably the prompting should be as similar as possible to C-x v r > and/or C-x v b s (which we might want to improve and/or unify first). Sounds good to me. > - C-x v w w: Switch to another working tree. > > This is a contextual command. When used in a file-visiting or dired > buffer, it means visit that same file name under one of the other > working trees. > > E.g. if you have worktrees for the Emacs master and release branches, > you can use it to hop between vc.el on master and vc.el on emacs-30. > In *vc-dir* it means to switch to *vc-dir* for the other worktree. > > Each working tree is already a separate project.el project, which is > what we want. This will be great! This is like project-find-matching-file but I think this worktree-specific version will be much more useful, since worktrees give us the knowledge that two projects are related and that lets us have the prompt be populated with much fewer options. > + If we keep the list of other working trees sorted by recency, then > C-x v w w RET would allow you to switch back and forth between (the > same file name in) your two most recently used working trees. > > - C-x v w s: A wrapper around C-x p p but with selection limited to > other working trees of this project. Sounds great. I suggest this should be done by let-binding project-prompter to a function which only prompts for the working trees related to the current project. Though: how are you thinking about prompting for working trees? At my site: - project-name is a short and sometimes-ambiguous name (since it's used widely in project.el in places that expect it to be short, e.g. project-prefixed-buffer-name), so just prompting with project-name would be undesirable. - And the directory of the worktree is also not very informative at my site. For this reason, I have a custom project-prompter configured at my site. Maybe vc backends should also be able to customize the prompting function used to prompt for working trees? > - C-x v w x: Delete a working tree. > > - C-x v w R: Relocate a working tree. > > Move or rename it, updating VC and project.el metadata as appropriate. > > BACKEND FUNCTIONS > > - other-working-trees: Return a list of all other working trees. > > - add-working-tree, delete-working-tree, move-working-tree. > > SVN BRANCHES > > Adding a new working tree is the same as creating a new branch, I think? > I think there are two ways we could go here: > > 1. Decide that SVN does not support other working trees in the sense of > these new commands, such that they are no-ops. > 2. Make the new commands effectively synonyms of existing branch-related > commands for SVN. IMO we should do 1 now until/unless someone requests 2. We can always do 2 later if we do 1 now, but if we do 2 now then we can never take it back if we decide it's wrong. > QUESTIONS > > - Are there other things that we might want to support that wouldn't be > covered by this API? I think this is a great start, I don't think this locks us into anything too bad. Later possible additions: the operation "make a new branch and worktree, and transfer the uncommitted changes from the current worktree to that new branch" (as we've discussed off-list) might be neat. Actually, in general, transferring uncommitted (or committed?) changes between worktrees would be a cool thing to support. I often find myself making vc-diff buffers and M-x cding in the buffer to other worktrees so that I can apply the changes in that buffer to the other worktree. Some first-class support might be cool. But I think we don't need to design that yet. > - Does project.el need to know about these relationships between trees, > or do we leave it all up to VC? I think the latter. I.e., from > project.el's point of view, each working tree is its own project. I agree. Adding support for "related projects" has often come up for project.el, but it's unclear how to design it. Keeping the worktree concept in vc avoids this, and we can always expose the knowledge to project.el later if we figure out a reason to do it. > - What shall we do with CVS/SVN branches? I've made two suggestions. > > - How are the bindings I've suggested? Intuitive enough? Yes - I particularly like C-x v w w; I think giving that an easy binding (the duplicated w) is very helpful, since I think for worktree users it's a fairly common operation. > Thank you in advance for any feedback. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 05:36:45 2025 Received: (at 79024) by debbugs.gnu.org; 18 Jul 2025 09:36:46 +0000 Received: from localhost ([127.0.0.1]:60686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uchWH-0005Lo-95 for submit@debbugs.gnu.org; Fri, 18 Jul 2025 05:36:45 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:35156) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uchWE-0005LB-3K for 79024@debbugs.gnu.org; Fri, 18 Jul 2025 05:36:43 -0400 DKIM-Signature: a=rsa-sha256; b=FxqQvL6JW0eXFWjidpt67yTWp85ZukEZlZXTGnkonVYx54BCmXr3N4J37A75H2GN+siHrf6mSubZuynLCmZJ9Jrc/JtzDdETc8NYeAdKEYSmsaAyMpvRzOxtmdQ5iIIvrudhbHJK5sNlJ6diML5+TJJ3y+7QDhDv7DwUcpXB68L+kYOSpH6UcwKpRnzxjY9FP9gpC03yGfcheDwCVClR3PUGED/NEmlnZODMpeq+aK1pd96w7Mvgwt1R+pWvW6mQNjgKyn3WvVxtRdRPhgTSuAGzKuwz0O38N/9YUgvapJqEpGtf52Onz/AuLJjoplo53xQ0D4KiO3r57c0MhZzZ4w==; s=purelymail1; d=spwhitton.name; v=1; bh=iqx8Ph6KrUUkLxR+49LwETrF0arNSTbP68kY+vHR3F0=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=hqSSRbCFTpMSOlBEE7AFyWheaEVGlJSMvkRFiWejIOScMhx9MjZhkYWjJj8JY0y6QuhSm87uCwRVmfS18JfGppwBRSWXBsPKZiDpyuBPNaAop8wqRC5Amdc0BZBYrzIIHYWK/oZeQ3cOnEEoYpeIqz05oSVhzTF0vYDoYMXGULmZL97/dMUypLWbYuq5hiX9s705OxVI/ySjtjE8secriefYr8DKBddrmDq9vnx/V0BRqmGzrEkibjAIBohdIJL07lTXJKrvnX6yFZTxEeSGMgR+ycg6nxMvZjKgtelytwu+eYkcVv7IwgDRHrrLvt1u1rJhmGiTBxbLDQqc4wxxTg==; s=purelymail1; d=purelymail.com; v=1; bh=iqx8Ph6KrUUkLxR+49LwETrF0arNSTbP68kY+vHR3F0=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79024@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1994724826; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Jul 2025 09:36:34 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 242D2941748; Fri, 18 Jul 2025 10:36:34 +0100 (BST) From: Sean Whitton To: Spencer Baugh , dmitry@gutov.dev Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC In-Reply-To: References: <87v7nt4qr9.fsf@zephyr.silentflame.com> Date: Fri, 18 Jul 2025 10:36:34 +0100 Message-ID: <87ldolzvq5.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: 79024 Cc: 79024@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 17 Jul 2025 at 01:24pm -04, Spencer Baugh wrote: >> - C-x v w s: A wrapper around C-x p p but with selection limited to >> other working trees of this project. > > Sounds great. I suggest this should be done by let-binding > project-prompter to a function which only prompts for the working trees > related to the current project. > > Though: how are you thinking about prompting for working trees? At my > site: > - project-name is a short and sometimes-ambiguous name (since it's > used widely in project.el in places that expect it to be short, > e.g. project-prefixed-buffer-name), so just prompting with project-name > would be undesirable. > - And the directory of the worktree is also not very informative at my > site. > > For this reason, I have a custom project-prompter configured at my site. > Maybe vc backends should also be able to customize the prompting > function used to prompt for working trees? I was thinking it would use the absolute file names of the project roots, as C-x p p does by default at present. But we wouldn't want to override a custom project prompter like yours. Indeed, project-prompter is a customisable user option, so we probably shouldn't be rebinding it. Seems to me like we want to extend the project-prompter API to allow filtering the list of projects the project prompter prompts for. Dmitry, what do you think about a new project-prompter-predicate which project prompters should use to filter the list of projects offered? VC could bind that to something which only lets through related worktrees. >> SVN BRANCHES >> >> Adding a new working tree is the same as creating a new branch, I think? >> I think there are two ways we could go here: >> >> 1. Decide that SVN does not support other working trees in the sense of >> these new commands, such that they are no-ops. >> 2. Make the new commands effectively synonyms of existing branch-related >> commands for SVN. > > IMO we should do 1 now until/unless someone requests 2. We can always > do 2 later if we do 1 now, but if we do 2 now then we can never take it > back if we decide it's wrong. Hmm yes, you're right, (1) lets us avoid getting stuck. >> QUESTIONS >> >> - Are there other things that we might want to support that wouldn't be >> covered by this API? > > I think this is a great start, I don't think this locks us into anything > too bad. > > Later possible additions: the operation "make a new branch and worktree, > and transfer the uncommitted changes from the current worktree to that > new branch" (as we've discussed off-list) might be neat. > > Actually, in general, transferring uncommitted (or committed?) changes > between worktrees would be a cool thing to support. I often find myself > making vc-diff buffers and M-x cding in the buffer to other worktrees so > that I can apply the changes in that buffer to the other worktree. Some > first-class support might be cool. But I think we don't need to design > that yet. Ah, yes, I do that too. I have a custom function in my init.el that does it using the git stash. But we could let Emacs handle it in a completely VC-agnostic way. As you say I don't think the details of this have to figured out now. > Yes - I particularly like C-x v w w; I think giving that an easy binding > (the duplicated w) is very helpful, since I think for worktree users > it's a fairly common operation. Nice. Thank you for the review :) -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 19 05:21:29 2025 Received: (at 79024) by debbugs.gnu.org; 19 Jul 2025 09:21:29 +0000 Received: from localhost ([127.0.0.1]:39942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ud3l3-0007zz-12 for submit@debbugs.gnu.org; Sat, 19 Jul 2025 05:21:29 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:56426) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ud3kz-0007zQ-Pf for 79024@debbugs.gnu.org; Sat, 19 Jul 2025 05:21:27 -0400 DKIM-Signature: a=rsa-sha256; b=s8F70gFc3SN0vxdjsbQQeLT20LXKKR6fhiFQrxNylgB7nJaEiB2OWMn1DHg1r4nFzu5yytEqWENQ8H6E3CRLwdT0aRh/tXf/79UVtvjNAXJ68w9Mfew51ZGEcuH5tJijgGfxk8Ubya2rCrudGAkAnUNLQIHJchzaam7fDXVV89u3Aa+LWpWlpng5JbK/7C19JinyU2yPPt7kkHyRvZD/+uigvh0h7LQ7IJwf0lojhksswYIwyBr41tNl8PYRuzB0JZy39sWo9+H9aKRKfi9Dz69qmSbnmE96aPoMix2zie10VgaERsQQYu6gEx0/YUJ70ZrDLBgzE3SvnNkxfiXVQA==; s=purelymail1; d=spwhitton.name; v=1; bh=KgW5nre190ax/Vj5ql2vHmeZfuUN5QgqjRarQjGQM0E=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=0UfDQu0YqNI+Nt0vVr8fXb0r6fa6WJlkUYmuuzuos2qzoZG7ibclQihfNLgswyNwCuMKmu9AmZ9OyZg01e6D5MZ9UaqDxFpRQ3A4cCOQcC4DDm2xLDAiZcX3ZtfYcdWAaEA3WAZBMb+4Vr0TAgUlmj5Uj0KvaMl3UnkW95Sv1TKWqnuAy54NtsPE/sz4hRpLeY4wtzrQ9smFl4CCW060TrEToVrnb86Y5YrEN2L5oYXmgJgepya1H7fALK9vhh+mxbdBqpzkctwX0IKYvqrDA63m+FW1JWP4jTSNOBXM5ToNKdwcD05Snr1EVAXH4/izNNKUsM7lhWW+tD71fpObMA==; s=purelymail1; d=purelymail.com; v=1; bh=KgW5nre190ax/Vj5ql2vHmeZfuUN5QgqjRarQjGQM0E=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 79024@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -759181042; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 19 Jul 2025 09:21:19 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 940F5940105; Sat, 19 Jul 2025 10:21:18 +0100 (BST) From: Sean Whitton To: 79024@debbugs.gnu.org Subject: Re: 31.0.50; Multiple working trees support for VC In-Reply-To: <87v7nt4qr9.fsf@zephyr.silentflame.com> References: <87v7nt4qr9.fsf@zephyr.silentflame.com> Date: Sat, 19 Jul 2025 10:21:18 +0100 Message-ID: <87y0sky1rl.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: 79024 Cc: dmitry@gutov.dev, 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 Tue 15 Jul 2025 at 12:50pm +01, Sean Whitton wrote: > BACKEND FUNCTIONS > > - other-working-trees: Return a list of all other working trees. > > - add-working-tree, delete-working-tree, move-working-tree. Here are my WIP specifications for these: ;; - other-working-trees () ;; ;; Return a list of all other working trees that use the same backing ;; repository as this working tree. The members of the list are the ;; absolute file names of the root directories of the other working ;; trees. ;; ;; - add-working-tree (directory) ;; ;; Create a new working tree at DIRECTORY that uses the same backing ;; repository as this working tree. ;; What gets checked out in DIRECTORY is left to the backend because ;; while some VCS can check out the same branch in multiple working ;; trees (e.g. Mercurial), others allow each branch to be checked out ;; in only one working tree (e.g. Git). ;; If a new branch should be created then the backend should handle ;; prompting for this, including prompting for a branch or tag from ;; which to start/fork the new branch, like `vc-create-branch'. ;; ;; - delete-working-tree (directory) ;; ;; Remove the working tree, assumed to be one that uses the same ;; backing repository as this working tree, at DIRECTORY. ;; ;; - move-working-tree (from to) ;; ;; Relocate the working tree, assumed to be one that uses the same ;; backing repository as this working tree, at FROM to TO. -- Sean Whitton