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>, dmitry <at> gutov.dev
Cc: 79024 <at> debbugs.gnu.org
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Fri, 18 Jul 2025 10:36:34 +0100

Hello,

On Thu 17 Jul 2025 at 01:24pm -04, Spencer Baugh wrote:

>> - C-x v w s: A wrapper around C-x p p but with selection limited to
>>   other working trees of this project.
>
> Sounds great.  I suggest this should be done by let-binding
> project-prompter to a function which only prompts for the working trees
> related to the current project.
>
> Though: how are you thinking about prompting for working trees?  At my
> site:
> - project-name is a short and sometimes-ambiguous name (since it's
> used widely in project.el in places that expect it to be short,
> e.g. project-prefixed-buffer-name), so just prompting with project-name
> would be undesirable.
> - And the directory of the worktree is also not very informative at my
> site.
>
> For this reason, I have a custom project-prompter configured at my site.
> Maybe vc backends should also be able to customize the prompting
> function used to prompt for working trees?

I was thinking it would use the absolute file names of the project
roots, as C-x p p does by default at present.  But we wouldn't want to
override a custom project prompter like yours.  Indeed, project-prompter
is a customisable user option, so we probably shouldn't be rebinding it.

Seems to me like we want to extend the project-prompter API to allow
filtering the list of projects the project prompter prompts for.

Dmitry, what do you think about a new project-prompter-predicate which
project prompters should use to filter the list of projects offered?  VC
could bind that to something which only lets through related worktrees.

>> 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.
>
> IMO we should do 1 now until/unless someone requests 2.  We can always
> do 2 later if we do 1 now, but if we do 2 now then we can never take it
> back if we decide it's wrong.

Hmm yes, you're right, (1) lets us avoid getting stuck.

>> QUESTIONS
>>
>> - Are there other things that we might want to support that wouldn't be
>>   covered by this API?
>
> I think this is a great start, I don't think this locks us into anything
> too bad.
>
> Later possible additions: the operation "make a new branch and worktree,
> and transfer the uncommitted changes from the current worktree to that
> new branch" (as we've discussed off-list) might be neat.
>
> Actually, in general, transferring uncommitted (or committed?) changes
> between worktrees would be a cool thing to support.  I often find myself
> making vc-diff buffers and M-x cding in the buffer to other worktrees so
> that I can apply the changes in that buffer to the other worktree.  Some
> first-class support might be cool.  But I think we don't need to design
> that yet.

Ah, yes, I do that too.  I have a custom function in my init.el that
does it using the git stash.  But we could let Emacs handle it in a
completely VC-agnostic way.  As you say I don't think the details of
this have to figured out now.

> Yes - I particularly like C-x v w w; I think giving that an easy binding
> (the duplicated w) is very helpful, since I think for worktree users
> it's a fairly common operation.

Nice.

Thank you for the review :)

-- 
Sean Whitton

Previous Next

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