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

Previous Next

Full log

View this message in rfc822 format

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: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Thu, 24 Jul 2025 16:09:17 +0100

Hello,

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

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> On Wed 23 Jul 2025 at 01:08pm -04, Spencer Baugh via "Bug reports for GNU
>> Emacs, the Swiss army knife of text editors" wrote:
>>
>>> IMO it would be fine to just look this up each time.
>>>
>>> The predicate passed to project-prompter would take the root directory
>>> of the project and decide whether that should be included in the prompt;
>>> and for hg shares, that would just be looking at .hg/sharedpath and
>>> checking if it has the right contents.  I think that one filesystem
>>> access is an acceptable cost, I don't think Emacs will need to maintain
>>> records of its own beyond the existing project--list.
>>
>> Hmm, well, vc-hg-other-working-trees has to look at every registered
>> project and decide if it is a related working tree; it has to be do this
>> independently of project-prompter or any of that machinery.  But there
>> could be a very large number of registered projects, and there'd be a
>> file access for each one.
>
> True, but what commands will run other-working-trees other than
> prompting for a worktree?
>
> In fact... do we even need other-working-trees at the moment?

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.

> Maybe all we want is a predicate, (vc-is-other-working-tree-p DIR1 DIR2)
> which checks that DIR1 and DIR2 are "other working trees" of each other.
>
> Or maybe (vc-working-tree-identity DIR) which returns a string
> identifying the "working tree family" of DIR.  Then this can be compared
> by string-equal to check if two dirs are "other working trees" of each
> other.
>
> That requires less from the VCS, and so is maybe more compatible with
> various VCSs - most obviously, hg.

I don't think I see how using these functions instead of
other-working-trees could avoid the performance problems inherent in a
very large project--list.

(Just to note, I do have all the backend functions I described above
implemented for Git and Hg now; I'm just working on tests.)

-- 
Sean Whitton

Previous Next

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