GNU bug report logs - #79024
31.0.50; Multiple working trees support for VC

Previous Next

Full log

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79024 <at> debbugs.gnu.org
Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Thu, 24 Jul 2025 21:26:29 +0100

Hello,

On Thu 24 Jul 2025 at 11:38am -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>> So far in my WIP code other-working-trees is indeed used only to prompt
>> for another working tree.  Looking to the future, though, giving Lisp
>> programs a way to obtain a list of all other working trees seems like
>> something we, or someone else, will want at some point.
>
> Naturally, but maybe we can wait until a use case appears?  (I do think
> there's some chance one never will appear)

This is a good question to ask, though as I'll argue below, unless I'm
missing something, the options are actually all closely equivalent and
so have roughly the same use cases.

> They would not avoid the performance problems - but if all we're going
> to do is pass a predicate to project-prompter which filters
> project--list, they would be better suited to that, since they're less
> powerful.  We would not need to mention project--list in vc at all then.

You can define vc-is-other-working-tree-p and other-working-trees in
terms of each other with only a little code:

--8<---------------cut here---------------start------------->8---
(defun vc-is-other-working-tree-p (dir1 dir2)
  (member dir2 (vc-call-backend (vc-responsible-backend dir1)
                                'other-working-trees)))

(defun vc-other-working-trees (dir1)
  (cl-remove-if-not (apply-partially #'vc-is-other-working-tree-p dir1)
                    (project-known-project-roots)))
--8<---------------cut here---------------end--------------->8---

I think this means they are equivalently powerful.  I think you could
make a similar argument for vc-working-tree-identity.

Then the question is, which is the better one to ask backend authors to
implement -- return a list of all other working trees, answer whether
two given trees are related, or return an identifying string for a
working tree?

For Git and Jujutsu, other-working-trees is extremely simple to
implement because they have a command to list all working trees.
The other two will be more complicated, but not very much more.

For Mercurial, returning an identifying string is easier to implement,
but again, the difference is fairly small.

So then I think we are left with considering overall simplicity and ease
of understanding, writing documentation, etc..  I think a backend
function that just returns a list of all other working trees is a bit
simpler than your two suggestions, but there's not much in it.

-- 
Sean Whitton

Previous Next

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