GNU bug report logs -
#79024
31.0.50; Multiple working trees support for VC
Previous Next
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
Message #50 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> 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.
True, using "git worktree list" to implement this is of course slow.
But my suggested implementation would be to simply read .git (which is a
file rather than a directory in git worktrees); then the performance
should be much better (just one file read).
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.