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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Sean Whitton <spwhitton <at> spwhitton.name>
Subject: bug#79024: closed (Re: bug#79024: 31.0.50; Multiple working trees
 support for VC)
Date: Sat, 16 Aug 2025 18:42:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#79024: 31.0.50; Multiple working trees support for VC

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 79024 <at> debbugs.gnu.org.

-- 
79024: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79024
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 79024-done <at> debbugs.gnu.org
Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Sat, 16 Aug 2025 19:40:52 +0100

Hello,

Excellent, thanks.  With your patch applied the tests pass here too.

Installed and closing the bug.

-- 
Sean Whitton

[Message part 3 (message/rfc822, inline)]

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Multiple working trees support for VC
Date: Tue, 15 Jul 2025 12:50:34 +0100

X-debbugs-cc: sbaugh <at> janestreet.com, dmitry <at> gutov.dev

Hello,

I would like to add support for multiple working trees to VC.  This is
'git worktree' for Git and 'hg share' for Mercurial.  It may or may not
map onto trunk/ vs. branch/ in SVN; see below.

TERMINOLOGY

VC's documentation consistently uses "working tree" to refer to what we
often also call the "working directory", "clone", "checkout".

I think that we can introduce the idea of "other working trees" and
commands that operate on them.  I don't believe we need to distinguish
between primary and secondary working trees, which is a VCS-specific
concept.  If a Git user tries to delete the primary worktree from a
secondary worktree, for example, it's just an error, signalled by the
relevant backend-specific function.

These commands would probably be meaningful only for changeset-based
VCS, not file-based VCS.

COMMANDS

- C-x v w c: Add a new working tree.

  The user must specify what branch, revision or tag to check out there.
  Probably the prompting should be as similar as possible to C-x v r
  and/or C-x v b s (which we might want to improve and/or unify first).

- C-x v w w: Switch to another working tree.

  This is a contextual command.  When used in a file-visiting or dired
  buffer, it means visit that same file name under one of the other
  working trees.

  E.g. if you have worktrees for the Emacs master and release branches,
  you can use it to hop between vc.el on master and vc.el on emacs-30.
  In *vc-dir* it means to switch to *vc-dir* for the other worktree.

  Each working tree is already a separate project.el project, which is
  what we want.

  + If we keep the list of other working trees sorted by recency, then
    C-x v w w RET would allow you to switch back and forth between (the
    same file name in) your two most recently used working trees.

- C-x v w s: A wrapper around C-x p p but with selection limited to
  other working trees of this project.

- C-x v w x: Delete a working tree.

- C-x v w R: Relocate a working tree.

  Move or rename it, updating VC and project.el metadata as appropriate.

BACKEND FUNCTIONS

- other-working-trees: Return a list of all other working trees.

- add-working-tree, delete-working-tree, move-working-tree.

SVN BRANCHES

Adding a new working tree is the same as creating a new branch, I think?
I think there are two ways we could go here:

1. Decide that SVN does not support other working trees in the sense of
   these new commands, such that they are no-ops.
2. Make the new commands effectively synonyms of existing branch-related
   commands for SVN.

QUESTIONS

- Are there other things that we might want to support that wouldn't be
  covered by this API?

- Does project.el need to know about these relationships between trees,
  or do we leave it all up to VC?  I think the latter.  I.e., from
  project.el's point of view, each working tree is its own project.

- What shall we do with CVS/SVN branches?  I've made two suggestions.

- How are the bindings I've suggested?  Intuitive enough?

Thank you in advance for any feedback.

-- 
Sean Whitton

Previous Next

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