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: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79024 <at> debbugs.gnu.org
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Thu, 24 Jul 2025 22:10:30 +0100

Hello,

On Thu 24 Jul 2025 at 04:40pm -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> I don't think so: if hg's other-working-trees is implemented by
> filtering project-known-project-roots (as we were considering earlier),
> then your implementation of vc-is-other-working-tree-p will erroneously
> return nil if dir2 is an hg share which is not in
> project-known-project-roots.
>
> For hg, a correct implementation would would be something like:
>
> (defun vc-hg-is-other-working-tree-p (dir1 dir2)
>   (string-equal (vc-hg-share-file-contents dir1)
>                 (vc-hg-share-file-contents dir2)))
>
> This would return the right answer every time, even if dir1 or dir2 is
> not in project--list.

Ah, I see now.

I have written vc-add-working-tree to call project-remember-project on
the newly created working tree, and so I was implicitly assuming that
all working trees would be known to project.el.

But that fails to account for working trees created from outside of VC.
And then, as you say, Mercurial becomes an impossible case.

Really, other-working-trees should be called known-other-working-trees.
The choice is between a function that can return an incomplete list and
one that always gives a complete and correct answer but requires passing
more parameters.

I'll give those two options some more thought.  Thanks!

-- 
Sean Whitton

Previous Next

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