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

Previous Next

Package: emacs;

Reported by: Sean Whitton <spwhitton <at> spwhitton.name>

Date: Tue, 15 Jul 2025 11:51:02 UTC

Severity: normal

Merged with 79104

Found in version 31.0.50

Done: Sean Whitton <spwhitton <at> spwhitton.name>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org, dmitry <at> gutov.dev
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Fri, 25 Jul 2025 17:44:45 +0300
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79024 <at> debbugs.gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 25 Jul 2025 15:30:49 +0100
> 
> Hello Spencer,
> 
> I just tried implementing an other-working-tree-p backend function for
> Git and Hg.  It introduces a new and quite significant performance
> problem for Git.  Consider prompting for another working tree like this:
> 
>     (completing-read prompt
>                      (cl-remove-if-not #'vc-git-other-working-tree-p
>                                        (project-known-project-roots))
>                      nil t)
> 
> This will call vc-git-other-working-tree-p multiple times, but the
> obvious implementation of vc-git-other-working-tree-p invokes 'git
> worktree list' to find its answer.  So this involves invoking 'git
> worktree list' over and over again, which is really slow.
> 
> This is VC-specific code which could be adapted somehow; the problem is
> worse if we are considering a project-prompter API where the project
> prompter receives only an opaque predicate function.  The
> project-prompter has no choice but to call the predicate repeatedly.
> 
> We could set up some caching of the results in vc-git but I can't think
> of a cache invalidation strategy that wouldn't break Lisp code trying to
> manipulate/maintain multiple worktrees.
> 
> Do let me know if you have thoughts, but it looks like we have to go
> with the other-working-trees API, renamed to known-other-working-trees.

Why does it have to be a separate backend?  Why cannot we rely on the
user to be aware that worktrees are involved, as he/she must when
invoking Git commands from the shell?




This bug report was last modified 5 days ago.

Previous Next


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