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: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79024 <at> debbugs.gnu.org
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Tue, 29 Jul 2025 05:16:21 +0300

Hi all,

On 25/07/2025 21:43, Spencer Baugh wrote:
>> I don't think implementing or not implementing it for Hg implies locking
>> into any API, and I've already implemented it, so I might as well
>> install it, I think.
> Well... if we didn't implement worktree-switching for vc-hg, then we
> could indeed have a reliable "other-working-trees" backend function,
> instead of "known-other-working-trees".  That's the lock-in, I guess.

A little late to this discussion, but if there is no strong conclusion 
on this question, personally a UI based on "other-working-trees" sounds 
a bit more useful: the user sees a fuller list, without having to visit 
each worktree first before it would be visible there.

It might be less friendly to some usage scenarios where people have a 
lot of worktrees, keeping the old ones around for a while. I'm not sure 
how popular is that. Seeing an old entry in the list might be a reminder 
to delete one, however.

So it can be something to decide based on the UI priorities.

As for Mercurial, maybe it's not that important to prioritize given 
Git's prevalence. But it could also have a halfway implementation - like 
scanning the parent directory of the current worktree for siblings 
(might not be great for large lists of worktrees, or more complex sets 
of worktrees), or reading the contents of some special file somewhere 
that would have to be written to manually (backend methods in vc-hg 
could also write to it, I suppose).

Previous Next

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