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

Previous Next

Full log

Message #59 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: Fri, 25 Jul 2025 11:29:30 -0400

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

> Hello,
>
> On Fri 25 Jul 2025 at 10:53am -04, Spencer Baugh wrote:
>
>> 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).
>
> Thought about this while running an errand after writing to you :)
>
> Unfortunately though there are git worktrees implemented where .git is a
> symlink to the relevant directory under .git/ in the main working tree
> (git-annex does this), and there is something called GIT_COMMON_DIR,
> which I just learned about, which affects worktree resolution.
>
> Reading git-worktree(1) and gitrepository-layout(5), there's a lot of
> implementation detail, which might change and vary across Git versions,
> to try to reproduce in vc-git.el.  Whereas 'git worktree list' is a
> stable interface.

Argh.  Okay, then yes, I think you're right that going with
known-other-working-trees is better.  And implementing it by just
filtering project-known-project-roots for vc-hg seems fine.

Or... maybe we could just not implement it for vc-hg?  Maybe vc-hg just
won't support switching to other worktrees?  At least at the start?

Previous Next

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