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

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
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 11:38:33 -0400

Sean Whitton <spwhitton <at> spwhitton.name> writes:
> 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.

Naturally, but maybe we can wait until a use case appears?  (I do think
there's some chance one never will appear)

>> 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.

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.

Previous Next

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