GNU bug report logs -
#79024
31.0.50; Multiple working trees support for VC
Previous Next
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Tue, 15 Jul 2025 11:51:02 UTC
Severity: normal
Merged with 79104
Found in version 31.0.50
Done: Sean Whitton <spwhitton <at> spwhitton.name>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 79024 in the body.
You can then email your comments to 79024 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
sbaugh <at> janestreet.com, dmitry <at> gutov.dev, bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 15 Jul 2025 11:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
New bug report received and forwarded. Copy sent to
sbaugh <at> janestreet.com, dmitry <at> gutov.dev, bug-gnu-emacs <at> gnu.org.
(Tue, 15 Jul 2025 11:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 17 Jul 2025 17:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> 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.
Exciting!
> 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.
Yes, that sounds good to me. This is ideal because this already matches
up well with the "worktree" terminology in Git.
I briefly considered proposing that command names use "vc-worktree"
instead of "vc-working-tree", but I actually think "vc-working-tree" is
better than "vc-worktree" because tab completion will expand "vc-w-t"
unambiguously to vc-working-tree but "vc-w" can't expand to vc-worktree.
> 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).
Sounds good to me.
> - 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.
This will be great! This is like project-find-matching-file but I think
this worktree-specific version will be much more useful, since worktrees
give us the knowledge that two projects are related and that lets us
have the prompt be populated with much fewer options.
> + 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.
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?
> - 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.
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.
> 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.
> - 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.
I agree. Adding support for "related projects" has often come up for
project.el, but it's unclear how to design it. Keeping the worktree
concept in vc avoids this, and we can always expose the knowledge to
project.el later if we figure out a reason to do it.
> - What shall we do with CVS/SVN branches? I've made two suggestions.
>
> - How are the bindings I've suggested? Intuitive enough?
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.
> Thank you in advance for any feedback.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 18 Jul 2025 09:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79024 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 19 Jul 2025 09:22:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 15 Jul 2025 at 12:50pm +01, Sean Whitton wrote:
> BACKEND FUNCTIONS
>
> - other-working-trees: Return a list of all other working trees.
>
> - add-working-tree, delete-working-tree, move-working-tree.
Here are my WIP specifications for these:
;; - other-working-trees ()
;;
;; Return a list of all other working trees that use the same backing
;; repository as this working tree. The members of the list are the
;; absolute file names of the root directories of the other working
;; trees.
;;
;; - add-working-tree (directory)
;;
;; Create a new working tree at DIRECTORY that uses the same backing
;; repository as this working tree.
;; What gets checked out in DIRECTORY is left to the backend because
;; while some VCS can check out the same branch in multiple working
;; trees (e.g. Mercurial), others allow each branch to be checked out
;; in only one working tree (e.g. Git).
;; If a new branch should be created then the backend should handle
;; prompting for this, including prompting for a branch or tag from
;; which to start/fork the new branch, like `vc-create-branch'.
;;
;; - delete-working-tree (directory)
;;
;; Remove the working tree, assumed to be one that uses the same
;; backing repository as this working tree, at DIRECTORY.
;;
;; - move-working-tree (from to)
;;
;; Relocate the working tree, assumed to be one that uses the same
;; backing repository as this working tree, at FROM to TO.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Mon, 21 Jul 2025 09:54:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
> 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.
I've got a second extension of project.el to ask about.
Mercurial doesn't maintain records of shared repositories.
The first repository knows nothing about shares created from it, and
each share only has a reference back to the first repository.
Therefore, to support the VC API for other working trees, Emacs needs to
maintain records of its own about other working trees for Mercurial
repositories.
Initially I'll implement this by just looking it up each time but that
will get slow. project--list's docstring talks about storing metadata
there. Could I perhaps treat the entries in project--list as plists or
alists, and push some entries there? I could use symbols with a vc--
prefix as the keys into the lists, indicating this is not data that
project.el itself should have much to do with? Or what do you think?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 23 Jul 2025 17:09:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
>
>> 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.
>
> I've got a second extension of project.el to ask about.
>
> Mercurial doesn't maintain records of shared repositories.
> The first repository knows nothing about shares created from it, and
> each share only has a reference back to the first repository.
>
> Therefore, to support the VC API for other working trees, Emacs needs to
> maintain records of its own about other working trees for Mercurial
> repositories.
>
> Initially I'll implement this by just looking it up each time but that
> will get slow. project--list's docstring talks about storing metadata
> there. Could I perhaps treat the entries in project--list as plists or
> alists, and push some entries there? I could use symbols with a vc--
> prefix as the keys into the lists, indicating this is not data that
> project.el itself should have much to do with? Or what do you think?
IMO it would be fine to just look this up each time.
The predicate passed to project-prompter would take the root directory
of the project and decide whether that should be included in the prompt;
and for hg shares, that would just be looking at .hg/sharedpath and
checking if it has the right contents. I think that one filesystem
access is an acceptable cost, I don't think Emacs will need to maintain
records of its own beyond the existing project--list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 14:19:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 23 Jul 2025 at 01:08pm -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> IMO it would be fine to just look this up each time.
>
> The predicate passed to project-prompter would take the root directory
> of the project and decide whether that should be included in the prompt;
> and for hg shares, that would just be looking at .hg/sharedpath and
> checking if it has the right contents. I think that one filesystem
> access is an acceptable cost, I don't think Emacs will need to maintain
> records of its own beyond the existing project--list.
Hmm, well, vc-hg-other-working-trees has to look at every registered
project and decide if it is a related working tree; it has to be do this
independently of project-prompter or any of that machinery. But there
could be a very large number of registered projects, and there'd be a
file access for each one.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 14:51:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> On Wed 23 Jul 2025 at 01:08pm -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> IMO it would be fine to just look this up each time.
>>
>> The predicate passed to project-prompter would take the root directory
>> of the project and decide whether that should be included in the prompt;
>> and for hg shares, that would just be looking at .hg/sharedpath and
>> checking if it has the right contents. I think that one filesystem
>> access is an acceptable cost, I don't think Emacs will need to maintain
>> records of its own beyond the existing project--list.
>
> Hmm, well, vc-hg-other-working-trees has to look at every registered
> project and decide if it is a related working tree; it has to be do this
> independently of project-prompter or any of that machinery. But there
> could be a very large number of registered projects, and there'd be a
> file access for each one.
True, but what commands will run other-working-trees other than
prompting for a worktree?
In fact... do we even need other-working-trees at the moment?
Maybe all we want is a predicate, (vc-is-other-working-tree-p DIR1 DIR2)
which checks that DIR1 and DIR2 are "other working trees" of each other.
Or maybe (vc-working-tree-identity DIR) which returns a string
identifying the "working tree family" of DIR. Then this can be compared
by string-equal to check if two dirs are "other working trees" of each
other.
That requires less from the VCS, and so is maybe more compatible with
various VCSs - most obviously, hg.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 15:10:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 24 Jul 2025 at 10:49am -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> On Wed 23 Jul 2025 at 01:08pm -04, Spencer Baugh via "Bug reports for GNU
>> Emacs, the Swiss army knife of text editors" wrote:
>>
>>> IMO it would be fine to just look this up each time.
>>>
>>> The predicate passed to project-prompter would take the root directory
>>> of the project and decide whether that should be included in the prompt;
>>> and for hg shares, that would just be looking at .hg/sharedpath and
>>> checking if it has the right contents. I think that one filesystem
>>> access is an acceptable cost, I don't think Emacs will need to maintain
>>> records of its own beyond the existing project--list.
>>
>> Hmm, well, vc-hg-other-working-trees has to look at every registered
>> project and decide if it is a related working tree; it has to be do this
>> independently of project-prompter or any of that machinery. But there
>> could be a very large number of registered projects, and there'd be a
>> file access for each one.
>
> True, but what commands will run other-working-trees other than
> prompting for a worktree?
>
> In fact... do we even need other-working-trees at the moment?
So far in my WIP code other-working-trees is indeed used only to prompt
for another working tree. Looking to the future, though, giving Lisp
programs a way to obtain a list of all other working trees seems like
something we, or someone else, will want at some point.
> Maybe all we want is a predicate, (vc-is-other-working-tree-p DIR1 DIR2)
> which checks that DIR1 and DIR2 are "other working trees" of each other.
>
> Or maybe (vc-working-tree-identity DIR) which returns a string
> identifying the "working tree family" of DIR. Then this can be compared
> by string-equal to check if two dirs are "other working trees" of each
> other.
>
> That requires less from the VCS, and so is maybe more compatible with
> various VCSs - most obviously, hg.
I don't think I see how using these functions instead of
other-working-trees could avoid the performance problems inherent in a
very large project--list.
(Just to note, I do have all the backend functions I described above
implemented for Git and Hg now; I'm just working on tests.)
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 15:39:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> On Thu 24 Jul 2025 at 10:49am -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>> Hello,
>>>
>>> On Wed 23 Jul 2025 at 01:08pm -04, Spencer Baugh via "Bug reports for GNU
>>> Emacs, the Swiss army knife of text editors" wrote:
>>>
>>>> IMO it would be fine to just look this up each time.
>>>>
>>>> The predicate passed to project-prompter would take the root directory
>>>> of the project and decide whether that should be included in the prompt;
>>>> and for hg shares, that would just be looking at .hg/sharedpath and
>>>> checking if it has the right contents. I think that one filesystem
>>>> access is an acceptable cost, I don't think Emacs will need to maintain
>>>> records of its own beyond the existing project--list.
>>>
>>> Hmm, well, vc-hg-other-working-trees has to look at every registered
>>> project and decide if it is a related working tree; it has to be do this
>>> independently of project-prompter or any of that machinery. But there
>>> could be a very large number of registered projects, and there'd be a
>>> file access for each one.
>>
>> True, but what commands will run other-working-trees other than
>> prompting for a worktree?
>>
>> In fact... do we even need other-working-trees at the moment?
>
> So far in my WIP code other-working-trees is indeed used only to prompt
> for another working tree. Looking to the future, though, giving Lisp
> programs a way to obtain a list of all other working trees seems like
> something we, or someone else, will want at some point.
Naturally, but maybe we can wait until a use case appears? (I do think
there's some chance one never will appear)
>> Maybe all we want is a predicate, (vc-is-other-working-tree-p DIR1 DIR2)
>> which checks that DIR1 and DIR2 are "other working trees" of each other.
>>
>> Or maybe (vc-working-tree-identity DIR) which returns a string
>> identifying the "working tree family" of DIR. Then this can be compared
>> by string-equal to check if two dirs are "other working trees" of each
>> other.
>>
>> That requires less from the VCS, and so is maybe more compatible with
>> various VCSs - most obviously, hg.
>
> I don't think I see how using these functions instead of
> other-working-trees could avoid the performance problems inherent in a
> very large project--list.
They would not avoid the performance problems - but if all we're going
to do is pass a predicate to project-prompter which filters
project--list, they would be better suited to that, since they're less
powerful. We would not need to mention project--list in vc at all then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 20:27:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 24 Jul 2025 at 11:38am -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>> So far in my WIP code other-working-trees is indeed used only to prompt
>> for another working tree. Looking to the future, though, giving Lisp
>> programs a way to obtain a list of all other working trees seems like
>> something we, or someone else, will want at some point.
>
> Naturally, but maybe we can wait until a use case appears? (I do think
> there's some chance one never will appear)
This is a good question to ask, though as I'll argue below, unless I'm
missing something, the options are actually all closely equivalent and
so have roughly the same use cases.
> They would not avoid the performance problems - but if all we're going
> to do is pass a predicate to project-prompter which filters
> project--list, they would be better suited to that, since they're less
> powerful. We would not need to mention project--list in vc at all then.
You can define vc-is-other-working-tree-p and other-working-trees in
terms of each other with only a little code:
--8<---------------cut here---------------start------------->8---
(defun vc-is-other-working-tree-p (dir1 dir2)
(member dir2 (vc-call-backend (vc-responsible-backend dir1)
'other-working-trees)))
(defun vc-other-working-trees (dir1)
(cl-remove-if-not (apply-partially #'vc-is-other-working-tree-p dir1)
(project-known-project-roots)))
--8<---------------cut here---------------end--------------->8---
I think this means they are equivalently powerful. I think you could
make a similar argument for vc-working-tree-identity.
Then the question is, which is the better one to ask backend authors to
implement -- return a list of all other working trees, answer whether
two given trees are related, or return an identifying string for a
working tree?
For Git and Jujutsu, other-working-trees is extremely simple to
implement because they have a command to list all working trees.
The other two will be more complicated, but not very much more.
For Mercurial, returning an identifying string is easier to implement,
but again, the difference is fairly small.
So then I think we are left with considering overall simplicity and ease
of understanding, writing documentation, etc.. I think a backend
function that just returns a list of all other working trees is a bit
simpler than your two suggestions, but there's not much in it.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 20:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> On Thu 24 Jul 2025 at 11:38am -04, Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>>> So far in my WIP code other-working-trees is indeed used only to prompt
>>> for another working tree. Looking to the future, though, giving Lisp
>>> programs a way to obtain a list of all other working trees seems like
>>> something we, or someone else, will want at some point.
>>
>> Naturally, but maybe we can wait until a use case appears? (I do think
>> there's some chance one never will appear)
>
> This is a good question to ask, though as I'll argue below, unless I'm
> missing something, the options are actually all closely equivalent and
> so have roughly the same use cases.
>
>> They would not avoid the performance problems - but if all we're going
>> to do is pass a predicate to project-prompter which filters
>> project--list, they would be better suited to that, since they're less
>> powerful. We would not need to mention project--list in vc at all then.
>
> You can define vc-is-other-working-tree-p and other-working-trees in
> terms of each other with only a little code:
>
> (defun vc-is-other-working-tree-p (dir1 dir2)
> (member dir2 (vc-call-backend (vc-responsible-backend dir1)
> 'other-working-trees)))
>
> (defun vc-other-working-trees (dir1)
> (cl-remove-if-not (apply-partially #'vc-is-other-working-tree-p dir1)
> (project-known-project-roots)))
>
> I think this means they are equivalently powerful. I think you could
> make a similar argument for vc-working-tree-identity.
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.
> Then the question is, which is the better one to ask backend authors to
> implement -- return a list of all other working trees, answer whether
> two given trees are related, or return an identifying string for a
> working tree?
>
> For Git and Jujutsu, other-working-trees is extremely simple to
> implement because they have a command to list all working trees.
> The other two will be more complicated, but not very much more.
>
> For Mercurial, returning an identifying string is easier to implement,
> but again, the difference is fairly small.
I don't think that's right, because for Mercurial it's simply impossible
to reliably implement other-working-trees. We've considered
implementing it with project--list, but that has the issue I mentioned
above.
Though, for what it's worth, I'm ultimately not that concerned about
this. My VC backend will not have a problem implementing
other-working-trees, so I don't care that much about the vc-hg
implementation.
> So then I think we are left with considering overall simplicity and ease
> of understanding, writing documentation, etc.. I think a backend
> function that just returns a list of all other working trees is a bit
> simpler than your two suggestions, but there's not much in it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 24 Jul 2025 21:11:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 79024 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 14:32:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello Spencer,
I just tried implementing an other-working-tree-p backend function for
Git and Hg. It introduces a new and quite significant performance
problem for Git. Consider prompting for another working tree like this:
(completing-read prompt
(cl-remove-if-not #'vc-git-other-working-tree-p
(project-known-project-roots))
nil t)
This will call vc-git-other-working-tree-p multiple times, but the
obvious implementation of vc-git-other-working-tree-p invokes 'git
worktree list' to find its answer. So this involves invoking 'git
worktree list' over and over again, which is really slow.
This is VC-specific code which could be adapted somehow; the problem is
worse if we are considering a project-prompter API where the project
prompter receives only an opaque predicate function. The
project-prompter has no choice but to call the predicate repeatedly.
We could set up some caching of the results in vc-git but I can't think
of a cache invalidation strategy that wouldn't break Lisp code trying to
manipulate/maintain multiple worktrees.
Do let me know if you have thoughts, but it looks like we have to go
with the other-working-trees API, renamed to known-other-working-trees.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 14:46:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79024 <at> debbugs.gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 25 Jul 2025 15:30:49 +0100
>
> Hello Spencer,
>
> I just tried implementing an other-working-tree-p backend function for
> Git and Hg. It introduces a new and quite significant performance
> problem for Git. Consider prompting for another working tree like this:
>
> (completing-read prompt
> (cl-remove-if-not #'vc-git-other-working-tree-p
> (project-known-project-roots))
> nil t)
>
> This will call vc-git-other-working-tree-p multiple times, but the
> obvious implementation of vc-git-other-working-tree-p invokes 'git
> worktree list' to find its answer. So this involves invoking 'git
> worktree list' over and over again, which is really slow.
>
> This is VC-specific code which could be adapted somehow; the problem is
> worse if we are considering a project-prompter API where the project
> prompter receives only an opaque predicate function. The
> project-prompter has no choice but to call the predicate repeatedly.
>
> We could set up some caching of the results in vc-git but I can't think
> of a cache invalidation strategy that wouldn't break Lisp code trying to
> manipulate/maintain multiple worktrees.
>
> Do let me know if you have thoughts, but it looks like we have to go
> with the other-working-trees API, renamed to known-other-working-trees.
Why does it have to be a separate backend? Why cannot we rely on the
user to be aware that worktrees are involved, as he/she must when
invoking Git commands from the shell?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 14:55:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello Spencer,
>
> I just tried implementing an other-working-tree-p backend function for
> Git and Hg. It introduces a new and quite significant performance
> problem for Git. Consider prompting for another working tree like this:
>
> (completing-read prompt
> (cl-remove-if-not #'vc-git-other-working-tree-p
> (project-known-project-roots))
> nil t)
>
> This will call vc-git-other-working-tree-p multiple times, but the
> obvious implementation of vc-git-other-working-tree-p invokes 'git
> worktree list' to find its answer. So this involves invoking 'git
> worktree list' over and over again, which is really slow.
>
> This is VC-specific code which could be adapted somehow; the problem is
> worse if we are considering a project-prompter API where the project
> prompter receives only an opaque predicate function. The
> project-prompter has no choice but to call the predicate repeatedly.
>
> We could set up some caching of the results in vc-git but I can't think
> of a cache invalidation strategy that wouldn't break Lisp code trying to
> manipulate/maintain multiple worktrees.
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 15:15:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79024 <at> debbugs.gnu.org (full text, mbox):
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.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 15:16:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 25 Jul 2025 at 05:44pm +03, Eli Zaretskii wrote:
> Why does it have to be a separate backend? Why cannot we rely on the
> user to be aware that worktrees are involved, as he/she must when
> invoking Git commands from the shell?
There's no separate backend, just some new backend functions, so I think
you misunderstood.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 15:30:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 79024 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 15:43:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org, dmitry <at> gutov.dev
> Date: Fri, 25 Jul 2025 16:15:27 +0100
>
> On Fri 25 Jul 2025 at 05:44pm +03, Eli Zaretskii wrote:
>
> > Why does it have to be a separate backend? Why cannot we rely on the
> > user to be aware that worktrees are involved, as he/she must when
> > invoking Git commands from the shell?
>
> There's no separate backend, just some new backend functions, so I think
> you misunderstood.
The question I asked still stands, regardless.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 16:56:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 25 Jul 2025 at 11:29am -04, Spencer Baugh wrote:
> 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?
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.
Indeed, Hg currently passes my tests and Git doesn't ...
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 16:57:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 25 Jul 2025 at 06:42pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org, dmitry <at> gutov.dev
>> Date: Fri, 25 Jul 2025 16:15:27 +0100
>>
>> On Fri 25 Jul 2025 at 05:44pm +03, Eli Zaretskii wrote:
>>
>> > Why does it have to be a separate backend? Why cannot we rely on the
>> > user to be aware that worktrees are involved, as he/she must when
>> > invoking Git commands from the shell?
>>
>> There's no separate backend, just some new backend functions, so I think
>> you misunderstood.
>
> The question I asked still stands, regardless.
You mean, why the new backend functions? To support the new user
commands. I've been using my WIP version to switch between vc.el on the
trunk and in my WIP worktree, it's very nice :)
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 18:15:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org
> Date: Fri, 25 Jul 2025 17:56:28 +0100
>
> Hello,
>
> On Fri 25 Jul 2025 at 06:42pm +03, Eli Zaretskii wrote:
>
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Cc: sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org, dmitry <at> gutov.dev
> >> Date: Fri, 25 Jul 2025 16:15:27 +0100
> >>
> >> On Fri 25 Jul 2025 at 05:44pm +03, Eli Zaretskii wrote:
> >>
> >> > Why does it have to be a separate backend? Why cannot we rely on the
> >> > user to be aware that worktrees are involved, as he/she must when
> >> > invoking Git commands from the shell?
> >>
> >> There's no separate backend, just some new backend functions, so I think
> >> you misunderstood.
> >
> > The question I asked still stands, regardless.
>
> You mean, why the new backend functions?
No, why would VC try to call worktree-related functions automatically,
without being told to do so by the user?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 18:37:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 25 Jul 2025 at 09:14pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: dmitry <at> gutov.dev, sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org
>> Date: Fri, 25 Jul 2025 17:56:28 +0100
>>
>> Hello,
>>
>> On Fri 25 Jul 2025 at 06:42pm +03, Eli Zaretskii wrote:
>>
>> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> >> Cc: sbaugh <at> janestreet.com, 79024 <at> debbugs.gnu.org, dmitry <at> gutov.dev
>> >> Date: Fri, 25 Jul 2025 16:15:27 +0100
>> >>
>> >> On Fri 25 Jul 2025 at 05:44pm +03, Eli Zaretskii wrote:
>> >>
>> >> > Why does it have to be a separate backend? Why cannot we rely on the
>> >> > user to be aware that worktrees are involved, as he/she must when
>> >> > invoking Git commands from the shell?
>> >>
>> >> There's no separate backend, just some new backend functions, so I think
>> >> you misunderstood.
>> >
>> > The question I asked still stands, regardless.
>>
>> You mean, why the new backend functions?
>
> No, why would VC try to call worktree-related functions automatically,
> without being told to do so by the user?
I don't believe it will.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Fri, 25 Jul 2025 18:44:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> On Fri 25 Jul 2025 at 11:29am -04, Spencer Baugh wrote:
>
>> 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?
>
> 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.
But anyway, I agree, might as well go ahead with
known-other-working-trees, that seems fine to have as the API.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 26 Jul 2025 07:03:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 79024 <at> debbugs.gnu.org (full text, mbox):
The new VC tests added under this discussion have 2 problems:
. Compiling the test file produces a warning:
In vc-test--other-working-trees:
lisp/vc/vc-tests/vc-tests.el:665:28: Warning: Unused lexical variable `tempdir'
. The new test fails for Git:
Registering (foo)...
Registering (foo)... done
Mark set
Press C-c C-c when you are done editing.
Enter a change comment. Type C-c C-c when done
Checking in foo...
Test vc-test-git07-other-working-trees backtrace:
signal(error ("Failed (status 128): git --no-pager commit -F c:/User
error("Failed (%s): %s" "status 128" "git --no-pager commit -F c:/Us
vc-do-command("*vc*" 0 "git" ("foo") "--no-pager" "commit" "-F" "c:/
apply(vc-do-command "*vc*" 0 "git" ("foo") "--no-pager" ("commit" "-
vc-git-command(nil 0 ("foo") "commit" "-F" "c:/Users/EliZ/AppData/Lo
apply(vc-git-command nil 0 ("foo") ("commit" "-F" "c:/Users/EliZ/App
vc-git-checkin(("foo") #("Summary: Testing other working trees\n" 0
apply(vc-git-checkin (("foo") #("Summary: Testing other working tree
vc-call-backend(Git checkin ("foo") #("Summary: Testing other workin
#f(compiled-function (backend rev patch-string files comment) #<byte
#f(compiled-function (files comment) #<bytecode 0x123ed96d95329748>)
vc-finish-logentry()
funcall-interactively(vc-finish-logentry)
call-interactively(vc-finish-logentry)
log-edit-done()
(let (vc-async-checkin) (log-edit-done))
(save-current-buffer (set-buffer (find-file-noselect tmp-name)) (vc-
(let* ((first (file-name-as-directory (expand-file-name "first" defa
(progn (add-hook 'vc-test--cleanup-hook (let ((dir default-directory
(unwind-protect (progn (add-hook 'vc-test--cleanup-hook (let ((dir d
(let ((vc-handled-backends (list backend)) (default-directory (file-
(progn (let ((vc-handled-backends (list backend)) (default-directory
(unwind-protect (progn (let ((vc-handled-backends (list backend)) (d
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
vc-test--other-working-trees(Git)
#f(lambda () :dynbind (let ((value-478 (gensym "ert-form-evaluation-
#f(compiled-function () #<bytecode 0x6e2b2fad8c7c862>)()
handler-bind-1(#f(compiled-function () #<bytecode 0x6e2b2fad8c7c862>
ert--run-test-internal(#s(ert--test-execution-info :test ... :result
ert-run-test(#s(ert-test :name vc-test-git07-other-working-trees :do
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msg5fr19l --only -- foo")
FAILED 24/56 vc-test-git07-other-working-trees (0.337804 sec) at lisp/vc/vc-tests/vc-tests.el:1
Is the new feature supposed to work on MS-Windows, where committing
specifies the message through a temporary file, rather than the
command line?
(The vc-test-hg07-other-working-trees test is skipped, perhaps the
version of Mercurial I have here is 4.7.1 or maybe "share" is an
add-on one should install and I didn't.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 26 Jul 2025 12:20:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 26 Jul 2025 at 10:02am +03, Eli Zaretskii wrote:
> The new VC tests added under this discussion have 2 problems:
>
> . Compiling the test file produces a warning:
>
> In vc-test--other-working-trees:
> lisp/vc/vc-tests/vc-tests.el:665:28: Warning: Unused lexical variable `tempdir'
Thanks. Is it deliberate that these files aren't compiled during a
regular build? I didn't know that files in test/lisp/ need to be
manually tested for problems like these.
> . The new test fails for Git:
>
> Test vc-test-git07-other-working-trees condition:
> (error
> "Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msg5fr19l --only -- foo")
> FAILED 24/56 vc-test-git07-other-working-trees (0.337804 sec) at lisp/vc/vc-tests/vc-tests.el:1
>
> Is the new feature supposed to work on MS-Windows, where committing
> specifies the message through a temporary file, rather than the
> command line?
It should work fine, this isn't about the new features, but just about
how I wrote the test setup. This is the relevant code:
--8<---------------cut here---------------start------------->8---
;; Set up the first working tree.
(make-directory first t)
(let ((default-directory first))
(vc-test--create-repo-function backend)
(write-region "foo" nil tmp-name nil 'nomessage)
(vc-register `(,backend (,(file-name-nondirectory tmp-name)))))
(with-current-buffer (find-file-noselect tmp-name)
(vc-checkin (list (file-name-nondirectory tmp-name)) backend)
(insert "Testing other working trees")
(let (vc-async-checkin)
(log-edit-done))
--8<---------------cut here---------------end--------------->8---
I tried to just copy what vc-test--version-diff did to create and
checkin a sample file. Does vc-test-git06-version-diff work for you?
> (The vc-test-hg07-other-working-trees test is skipped, perhaps the
> version of Mercurial I have here is 4.7.1 or maybe "share" is an
> add-on one should install and I didn't.)
You don't have to install it but you do have to enable it in your
personal ~/.hgrc runtime configuration file. Add this to that file:
[extensions]
share =
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 26 Jul 2025 13:51:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sat, 26 Jul 2025 13:19:29 +0100
>
> Hello,
>
> On Sat 26 Jul 2025 at 10:02am +03, Eli Zaretskii wrote:
>
> > The new VC tests added under this discussion have 2 problems:
> >
> > . Compiling the test file produces a warning:
> >
> > In vc-test--other-working-trees:
> > lisp/vc/vc-tests/vc-tests.el:665:28: Warning: Unused lexical variable `tempdir'
>
> Thanks. Is it deliberate that these files aren't compiled during a
> regular build? I didn't know that files in test/lisp/ need to be
> manually tested for problems like these.
I don't understand the question. The test files are compiled when the
test is run, if the .elc file is outdated.
> > Test vc-test-git07-other-working-trees condition:
> > (error
> > "Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msg5fr19l --only -- foo")
> > FAILED 24/56 vc-test-git07-other-working-trees (0.337804 sec) at lisp/vc/vc-tests/vc-tests.el:1
> >
> > Is the new feature supposed to work on MS-Windows, where committing
> > specifies the message through a temporary file, rather than the
> > command line?
>
> It should work fine, this isn't about the new features, but just about
> how I wrote the test setup. This is the relevant code:
>
> --8<---------------cut here---------------start------------->8---
> ;; Set up the first working tree.
> (make-directory first t)
> (let ((default-directory first))
> (vc-test--create-repo-function backend)
> (write-region "foo" nil tmp-name nil 'nomessage)
> (vc-register `(,backend (,(file-name-nondirectory tmp-name)))))
> (with-current-buffer (find-file-noselect tmp-name)
> (vc-checkin (list (file-name-nondirectory tmp-name)) backend)
> (insert "Testing other working trees")
> (let (vc-async-checkin)
> (log-edit-done))
> --8<---------------cut here---------------end--------------->8---
>
> I tried to just copy what vc-test--version-diff did to create and
> checkin a sample file. Does vc-test-git06-version-diff work for you?
Yes.
This test fails on GNU/Linux as well for me, but for a different
reason:
Test vc-test-git07-other-working-trees backtrace:
write-region(nil nil "~/.emacs.d/projects.eld" nil silent)
project--write-project-list()
project--remember-dir("/tmp/vc-testxQfvm1/first/" nil)
project-remember-project((vc Git "/tmp/vc-testxQfvm1/first/"))
vc-add-working-tree(Git "/tmp/vc-testxQfvm1/second/")
(progn (fset 'completing-read vnew) (vc-add-working-tree backend sec
(unwind-protect (progn (fset 'completing-read vnew) (vc-add-working-
(let* ((vnew #'(lambda (&rest _ignore) "")) (old (symbol-function 'c
(cond ((eql backend 'Git) (let* ((vnew #'(lambda (&rest _ignore) "")
(save-current-buffer (set-buffer (find-file-noselect tmp-name)) (vc-
(let* ((first (file-name-as-directory (expand-file-name "first" defa
(progn (add-hook 'vc-test--cleanup-hook (let ((dir default-directory
(unwind-protect (progn (add-hook 'vc-test--cleanup-hook (let ((dir d
(let ((vc-handled-backends (list backend)) (default-directory (file-
(progn (let ((vc-handled-backends (list backend)) (default-directory
(unwind-protect (progn (let ((vc-handled-backends (list backend)) (d
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
vc-test--other-working-trees(Git)
#f(lambda () :dynbind (let ((value-478 (gensym "ert-form-evaluation-
#f(compiled-function () #<bytecode 0x67538246abce8e>)()
handler-bind-1(#f(compiled-function () #<bytecode 0x67538246abce8e>)
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name vc-test-git07-other-working-trees :do
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test vc-test-git07-other-working-trees condition:
(file-missing "Opening output file" "No such file or directory"
"/nonexistent/.emacs.d/projects.eld")
FAILED 24/56 vc-test-git07-other-working-trees (0.120713 sec) at lisp/vc/vc
Maybe this fails because my Git is very old? (It does support
worktrees, though.) If you could show a series of shell commands this
test invokes, I could perhaps run them from the shell and see what
happens.
> > (The vc-test-hg07-other-working-trees test is skipped, perhaps the
> > version of Mercurial I have here is 4.7.1 or maybe "share" is an
> > add-on one should install and I didn't.)
>
> You don't have to install it but you do have to enable it in your
> personal ~/.hgrc runtime configuration file. Add this to that file:
>
> [extensions]
> share =
OK, did that (perhaps this should be in the comments to the test?).
But the test is still skipped. I think I understand why: we run the
test suite with a bogus HOME directory, so the real ~/.hgrc is not
used, and "hg share" says "unknown command". I see the same on
GNU/Linux, so this is not specific to Windows. Does the test work for
you?
Merged 79024 79104.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sun, 27 Jul 2025 04:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 27 Jul 2025 08:43:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 26 Jul 2025 at 04:49pm +03, Eli Zaretskii wrote:
> I don't understand the question. The test files are compiled when the
> test is run, if the .elc file is outdated.
But if you just do 'make' in the root of the source tree, they're not
recompiled, right? Otherwise I would have seen and fixed the warning.
Is that deliberate? Even if we don't run the tests as part of the
build, we could compile them, and therefore be more likely to notice
problems like this.
> Test vc-test-git07-other-working-trees condition:
> (file-missing "Opening output file" "No such file or directory"
> "/nonexistent/.emacs.d/projects.eld")
> FAILED 24/56 vc-test-git07-other-working-trees (0.120713 sec) at lisp/vc/vc
>
> Maybe this fails because my Git is very old? (It does support
> worktrees, though.) If you could show a series of shell commands this
> test invokes, I could perhaps run them from the shell and see what
> happens.
> [...]
> OK, did that (perhaps this should be in the comments to the test?).
> But the test is still skipped. I think I understand why: we run the
> test suite with a bogus HOME directory, so the real ~/.hgrc is not
> used, and "hg share" says "unknown command". I see the same on
> GNU/Linux, so this is not specific to Windows. Does the test work for
> you?
Thanks, I didn't see these issues previously because I had been running
the tests only interactively.
Now rectified that and sorted out enabling the share extension for hg
and fixed the /nonexistent/.emacs.d/project.eld issue.
The tests still do not pass because after executing the line
;; Test `move-working-tree'.
(vc-move-working-tree backend second third)
there is then an error, at some point:
error in process sentinel: Setting current directory: No such file or directory, /tmp/vc-testfFGMCu/second/
I haven't yet been able to determine what is causing this process
sentinel left behind in the 'second' working tree (that the test renames
out of existence).
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 27 Jul 2025 09:18:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sun, 27 Jul 2025 09:42:31 +0100
>
> Hello,
>
> On Sat 26 Jul 2025 at 04:49pm +03, Eli Zaretskii wrote:
>
> > I don't understand the question. The test files are compiled when the
> > test is run, if the .elc file is outdated.
>
> But if you just do 'make' in the root of the source tree, they're not
> recompiled, right? Otherwise I would have seen and fixed the warning.
"make" builds Emacs, but doesn't run the test suite. This is similar
to what other projects do: to run the test suite, you need to say
"make check".
Since the entire test suite takes quite some time to run, I usually
run only the relevant test(s), like this:
make -C test lisp/some-tests
(assuming the test file is test/lisp/some-tests.el). Some changes
need to run more than one test file.
> Is that deliberate? Even if we don't run the tests as part of the
> build, we could compile them, and therefore be more likely to notice
> problems like this.
I'm not sure it would be TRT to have "make" do anything in the test
suite, no.
> > Test vc-test-git07-other-working-trees condition:
> > (file-missing "Opening output file" "No such file or directory"
> > "/nonexistent/.emacs.d/projects.eld")
> > FAILED 24/56 vc-test-git07-other-working-trees (0.120713 sec) at lisp/vc/vc
> >
> > Maybe this fails because my Git is very old? (It does support
> > worktrees, though.) If you could show a series of shell commands this
> > test invokes, I could perhaps run them from the shell and see what
> > happens.
Paul now posted an almost identical failure, so I don't think this has
anything to do with my Git version.
> > OK, did that (perhaps this should be in the comments to the test?).
> > But the test is still skipped. I think I understand why: we run the
> > test suite with a bogus HOME directory, so the real ~/.hgrc is not
> > used, and "hg share" says "unknown command". I see the same on
> > GNU/Linux, so this is not specific to Windows. Does the test work for
> > you?
>
> Thanks, I didn't see these issues previously because I had been running
> the tests only interactively.
> Now rectified that and sorted out enabling the share extension for hg
> and fixed the /nonexistent/.emacs.d/project.eld issue.
>
> The tests still do not pass because after executing the line
>
> ;; Test `move-working-tree'.
> (vc-move-working-tree backend second third)
>
> there is then an error, at some point:
>
> error in process sentinel: Setting current directory: No such file or directory, /tmp/vc-testfFGMCu/second/
>
> I haven't yet been able to determine what is causing this process
> sentinel left behind in the 'second' working tree (that the test renames
> out of existence).
That's not what I see here. The Git test still fails in the same way:
Registering (foo)...
Registering (foo)... done
Mark set
Press C-c C-c when you are done editing.
Enter a change comment. Type C-c C-c when done
Checking in foo...
Test vc-test-git07-other-working-trees backtrace:
signal(error ("Failed (status 128): git --no-pager commit -F c:/User
error("Failed (%s): %s" "status 128" "git --no-pager commit -F c:/Us
vc-do-command("*vc*" 0 "git" ("foo") "--no-pager" "commit" "-F" "c:/
apply(vc-do-command "*vc*" 0 "git" ("foo") "--no-pager" ("commit" "-
vc-git-command(nil 0 ("foo") "commit" "-F" "c:/Users/EliZ/AppData/Lo
apply(vc-git-command nil 0 ("foo") ("commit" "-F" "c:/Users/EliZ/App
vc-git-checkin(("foo") #("Summary: Testing other working trees\n" 0
apply(vc-git-checkin (("foo") #("Summary: Testing other working tree
vc-call-backend(Git checkin ("foo") #("Summary: Testing other workin
#f(compiled-function (backend rev patch-string files comment) #<byte
#f(compiled-function (files comment) #<bytecode 0x123ed980b51f4b48>)
vc-finish-logentry()
funcall-interactively(vc-finish-logentry)
call-interactively(vc-finish-logentry)
log-edit-done()
(let (vc-async-checkin) (log-edit-done))
(save-current-buffer (set-buffer (find-file-noselect tmp-name)) (vc-
(let* ((first (file-name-as-directory (expand-file-name "first" defa
(progn (add-hook 'vc-test--cleanup-hook (let ((dir default-directory
(unwind-protect (progn (add-hook 'vc-test--cleanup-hook (let ((dir d
(let ((vc-handled-backends (list backend)) (default-directory (file-
(progn (let ((vc-handled-backends (list backend)) (default-directory
(unwind-protect (progn (let ((vc-handled-backends (list backend)) (d
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
vc-test--other-working-trees(Git)
(let ((vc-hg-global-switches (cons "--config=extensions.share=" vc-h
#f(lambda () :dynbind (let ((value-478 (gensym "ert-form-evaluation-
#f(compiled-function () #<bytecode 0x7b91ca0e300b608>)()
handler-bind-1(#f(compiled-function () #<bytecode 0x7b91ca0e300b608>
ert--run-test-internal(#s(ert--test-execution-info :test ... :result
ert-run-test(#s(ert-test :name vc-test-git07-other-working-trees :do
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msgexkgWo --only -- foo")
FAILED 24/56 vc-test-git07-other-working-trees (0.357570 sec) at lisp/vc/vc-tests/vc-tests.el:1
And the corresponding Hg test fails like this:
Registering (foo)...
Registering (foo)... done
Mark set
Press C-c C-c when you are done editing.
Enter a change comment. Type C-c C-c when done
Checking in foo...
Test vc-test-hg07-other-working-trees backtrace:
signal(error ("Failed (status 255): hg --config ui.report_untrusted=
error("Failed (%s): %s" "status 255" "hg --config ui.report_untruste
vc-do-command("*vc*" 0 "hg" ("foo") "--config" "ui.report_untrusted=
apply(vc-do-command ("*vc*" 0 "hg" ("foo") "--config" "ui.report_unt
vc-hg--command-1(vc-do-command ("*vc*" 0 "hg" ("foo")) ("commit" "-m
vc-hg-command(nil 0 ("foo") "commit" "-m" "Testing other working tre
apply(vc-hg-command nil 0 ("foo") ("commit" "-m" "Testing other work
vc-hg-checkin(("foo") #("Summary: Testing other working trees\nTesti
apply(vc-hg-checkin (("foo") #("Summary: Testing other working trees
vc-call-backend(Hg checkin ("foo") #("Summary: Testing other working
#f(compiled-function (backend rev patch-string files comment) #<byte
#f(compiled-function (files comment) #<bytecode 0x123ed980b54f4b48>)
vc-finish-logentry()
funcall-interactively(vc-finish-logentry)
call-interactively(vc-finish-logentry)
log-edit-done()
(let (vc-async-checkin) (log-edit-done))
(save-current-buffer (set-buffer (find-file-noselect tmp-name)) (vc-
(let* ((first (file-name-as-directory (expand-file-name "first" defa
(progn (add-hook 'vc-test--cleanup-hook (let ((dir default-directory
(unwind-protect (progn (add-hook 'vc-test--cleanup-hook (let ((dir d
(let ((vc-handled-backends (list backend)) (default-directory (file-
(progn (let ((vc-handled-backends (list backend)) (default-directory
(unwind-protect (progn (let ((vc-handled-backends (list backend)) (d
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
vc-test--other-working-trees(Hg)
(let ((vc-hg-global-switches (cons "--config=extensions.share=" vc-h
#f(lambda () :dynbind (let ((value-511 (gensym "ert-form-evaluation-
#f(compiled-function () #<bytecode 0x7b91ca0e300b608>)()
handler-bind-1(#f(compiled-function () #<bytecode 0x7b91ca0e300b608>
ert--run-test-internal(#s(ert--test-execution-info :test ... :result
ert-run-test(#s(ert-test :name vc-test-hg07-other-working-trees :doc
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test vc-test-hg07-other-working-trees condition:
(error
"Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -m Testing other working trees\n\nTesting other working trees\n foo")
FAILED 32/56 vc-test-hg07-other-working-trees (0.424025 sec) at lisp/vc/vc-tests/vc-tests.el:1
I think that's because MS-Windows doesn't support command lines with
embedded newlines (see the -m switch above), so we need to use the
same trick with a temporary file as we do in Git.
On GNU/Linux, the Git test fails like this:
Checking in foo...
Checking in foo...done
Test vc-test-git07-other-working-trees backtrace:
signal(error ("Failed (status 129): git --no-pager worktree list --p
apply(signal (error ("Failed (status 129): git --no-pager worktree l
(setq value-239 (apply fn-237 args-238))
(unwind-protect (setq value-239 (apply fn-237 args-238)) (setq form-
(if (unwind-protect (setq value-239 (apply fn-237 args-238)) (setq f
(let (form-description-241) (if (unwind-protect (setq value-239 (app
(let ((value-239 'ert-form-evaluation-aborted-240)) (let (form-descr
(let* ((fn-237 #'equal) (args-238 (condition-case err (list (list se
(save-current-buffer (set-buffer (find-file-noselect tmp-name)) (let
(let* ((first (file-name-as-directory (expand-file-name "first" defa
(progn (add-hook 'vc-test--cleanup-hook (let ((dir default-directory
(unwind-protect (progn (add-hook 'vc-test--cleanup-hook (let ((dir d
(let ((vc-handled-backends (list backend)) (default-directory (file-
(progn (let ((vc-handled-backends (list backend)) (default-directory
(unwind-protect (progn (let ((vc-handled-backends (list backend)) (d
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
vc-test--other-working-trees(Git)
(let ((vc-hg-global-switches (cons "--config=extensions.share=" vc-h
#f(lambda () :dynbind (let ((value-478 (gensym "ert-form-evaluation-
#f(compiled-function () #<bytecode 0x6a0ab5e05cce532>)()
handler-bind-1(#f(compiled-function () #<bytecode 0x6a0ab5e05cce532>
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name vc-test-git07-other-working-trees :do
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 129): git --no-pager worktree list --porcelain -z")
FAILED 24/56 vc-test-git07-other-working-trees (0.191993 sec) at lisp/vc/vc-tests/vc-tests.el:1
And hg07-other-working-trees indeed fails like you say:
Checking in foo...
Checking in foo...done
error in process sentinel: Setting current directory: No such file or directory, /tmp/vc-testC5QRAj/second/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 27 Jul 2025 19:48:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 27 Jul 2025 at 12:17pm +03, Eli Zaretskii wrote:
> "make" builds Emacs, but doesn't run the test suite. This is similar
> to what other projects do: to run the test suite, you need to say
> "make check".
>
> Since the entire test suite takes quite some time to run, I usually
> run only the relevant test(s), like this:
>
> make -C test lisp/some-tests
>
> (assuming the test file is test/lisp/some-tests.el). Some changes
> need to run more than one test file.
Right. But other projects I've worked with often always build the tests
even if they don't run them. But I can see arguments against doing
that, too.
> Paul now posted an almost identical failure, so I don't think this has
> anything to do with my Git version.
Agreed.
I pushed a fix just now which makes all the tests pass for me on
GNU/Linux. If that doesn't also fix the Git tests for you on Windows,
then I'm not sure what else could be wrong.
As for Mercurial, I can implement the temporary file thing again, but
I'd like to know about line endings first.
If you do 'hg init' in a temporary directory, 'echo foo >bar', put a
commit message containing DOS line breaks in a temporary file, and do
'hg commit bar --logfile=temp', does the commit message that gets
recorded look correct?
With Git we have to switch back to Unix line endings while writing out
the temporary file because Git expects that; I would assume Mercurial
does not, but I'm not sure.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Mon, 28 Jul 2025 12:32:01 GMT)
Full text and
rfc822 format available.
Message #100 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sun, 27 Jul 2025 20:46:56 +0100
>
> > Since the entire test suite takes quite some time to run, I usually
> > run only the relevant test(s), like this:
> >
> > make -C test lisp/some-tests
> >
> > (assuming the test file is test/lisp/some-tests.el). Some changes
> > need to run more than one test file.
>
> Right. But other projects I've worked with often always build the tests
> even if they don't run them.
Some do, some don't.
> I pushed a fix just now which makes all the tests pass for me on
> GNU/Linux.
It still fails on GNU/Linux for me:
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 129): git --no-pager worktree list --porcelain -z")
FAILED 24/56 vc-test-git07-other-working-trees (0.145203 sec) at lisp/vc/vc-tests/vc-tests.el:1
> If that doesn't also fix the Git tests for you on Windows,
> then I'm not sure what else could be wrong.
Yes, it still faisl on Windows, with the same error as previously:
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msgLSkxp8 --only -- foo")
FAILED 24/56 vc-test-git07-other-working-trees (0.343783 sec) at lisp/vc/vc-tests/vc-tests.el:1
Please show the Git commands we issue during this test, and I will try
running them from the shell to see what's going on and why.
> As for Mercurial, I can implement the temporary file thing again, but
> I'd like to know about line endings first.
>
> If you do 'hg init' in a temporary directory, 'echo foo >bar', put a
> commit message containing DOS line breaks in a temporary file, and do
> 'hg commit bar --logfile=temp', does the commit message that gets
> recorded look correct?
How do I determine whether the recorded log message "looks correct"?
> With Git we have to switch back to Unix line endings while writing out
> the temporary file because Git expects that; I would assume Mercurial
> does not, but I'm not sure.
I don't think it matters with Mercurial, and it can never do any harm
to use Unix EOLs, I think.
A more important question is the encoding: does hg expect the commit
log messages to be in UTF-8, or does it not care, or something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Mon, 28 Jul 2025 19:56:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 28 Jul 2025 at 03:30pm +03, Eli Zaretskii wrote:
>> I pushed a fix just now which makes all the tests pass for me on
>> GNU/Linux.
>
> It still fails on GNU/Linux for me:
>
> Test vc-test-git07-other-working-trees condition:
> (error
> "Failed (status 129): git --no-pager worktree list --porcelain -z")
> FAILED 24/56 vc-test-git07-other-working-trees (0.145203 sec) at lisp/vc/vc-tests/vc-tests.el:1
>
>> If that doesn't also fix the Git tests for you on Windows,
>> then I'm not sure what else could be wrong.
>
> Yes, it still faisl on Windows, with the same error as previously:
>
> Test vc-test-git07-other-working-trees condition:
> (error
> "Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msgLSkxp8 --only -- foo")
> FAILED 24/56 vc-test-git07-other-working-trees (0.343783 sec) at lisp/vc/vc-tests/vc-tests.el:1
>
> Please show the Git commands we issue during this test, and I will try
> running them from the shell to see what's going on and why.
Okay, based on adding some tracing to vc-git-command and vc-git--call,
and inserting 'mv' and 'cd' commands to correspond to other things the
test does, this is what I have for you:
mkdir first
cd first
git init
# create 'foo'
git --no-pager ls-files -c -z -- foo
git --no-pager ls-tree --name-only -z HEAD -- foo
git update-index --add -- foo
git --no-pager ls-files -c -z -- foo
git --no-pager status --porcelain -z --untracked-files --ignored -- foo
git --no-pager rev-parse HEAD
git --no-pager symbolic-ref HEAD
git commit -F c:/Users/... --only -- foo # make a commit msg temp file
git --no-pager rev-parse HEAD
git for-each-ref --format=%(refname) -- nil
git worktree add --detach ../second/
git worktree prune
git worktree list --porcelain -z
cd ../second
git worktree prune
git worktree list --porcelain -z
cd ../first
mv ../second ../third
git worktree repair
git worktree prune
git worktree list --porcelain -z
cd ../third
mv ../first ../second
git worktree repair
git worktree prune
git worktree list --porcelain -z
mv ../second ../first
git worktree repair
cd ../first
git update-index --refresh
git --no-pager rev-parse --verify HEAD
git diff-index --relative -z -M HEAD --
git ls-files -z -d --
git ls-files -z -u --
git ls-files -z -o --exclude-standard --
git worktree remove -f ../third/
>> As for Mercurial, I can implement the temporary file thing again, but
>> I'd like to know about line endings first.
>>
>> If you do 'hg init' in a temporary directory, 'echo foo >bar', put a
>> commit message containing DOS line breaks in a temporary file, and do
>> 'hg commit bar --logfile=temp', does the commit message that gets
>> recorded look correct?
>
> How do I determine whether the recorded log message "looks correct"?
>> With Git we have to switch back to Unix line endings while writing out
>> the temporary file because Git expects that; I would assume Mercurial
>> does not, but I'm not sure.
>
> I don't think it matters with Mercurial, and it can never do any harm
> to use Unix EOLs, I think.
Okay.
> A more important question is the encoding: does hg expect the commit
> log messages to be in UTF-8, or does it not care, or something else?
<https://wiki.mercurial-scm.org/EncodingStrategy#UTF-8_strings> makes it
sound like the file is assumed to be in the local encoding and then gets
converted. However, that page has not been updated for ten years.
There is an option --encoding that one can pass. It defaults to utf-8.
That makes it seem like we could write out the commit message in UTF-8
and know it'll be okay.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 29 Jul 2025 02:17:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 79024 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 29 Jul 2025 02:47:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 79024 <at> debbugs.gnu.org (full text, mbox):
On 15/07/2025 14:50, Sean Whitton wrote:
> - 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.
Strictly speaking, any of the other worktree directories might not be
recognized by project.el as projects, if the user had set up their own
special backend and removed the default one.
But we probably don't have to be concerned about this scenario too much,
if otherwise we save a bunch of work in implementation.
> - How are the bindings I've suggested? Intuitive enough?
The bindinds look nice to me too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 29 Jul 2025 13:21:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 29 Jul 2025 at 05:16am +03, Dmitry Gutov wrote:
> 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).
These are interesting suggestions, thanks. We can see how people do
with what's implemented now and potentially add these.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 29 Jul 2025 13:22:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello Dmitry,
I think you missed this request for input here. Would you be able to
take a look? Thanks.
On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
> 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.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 30 Jul 2025 02:26:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hi Sean,
On 29/07/2025 16:21, Sean Whitton wrote:
> I think you missed this request for input here. Would you be able to
> take a look? Thanks.
>
> On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
>
>> 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.
I guess my answer is maybe.
Ideally we should be able to think of some other usage scenarios as
well, not just from this worktree feature. Maybe add them to the docstring.
Questions about implementation:
Will 'project-known-project-roots' use (and be affected by) that predicate?
Could someone set it up one day and then later see a project-list entry
stay around in the file but never come up in the prompt, or never be
cleared by project-forget-zombie-projects?
Also IIUC if we consider the "other-working-trees API" approach, I guess
it wouldn't exactly fit as a solution, because we'd want to substitute
the full list instead of filtering. (Is that right?) Then an alternative
could be just a separate user option for the prompter function here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 30 Jul 2025 11:01:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 30 Jul 2025 at 05:24am +03, Dmitry Gutov wrote:
> Hi Sean,
>
> On 29/07/2025 16:21, Sean Whitton wrote:
>> I think you missed this request for input here. Would you be able to
>> take a look? Thanks.
>> On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
>>
>>> 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.
>
> I guess my answer is maybe.
>
> Ideally we should be able to think of some other usage scenarios as well, not
> just from this worktree feature. Maybe add them to the docstring.
Right. I can most readily imagine code that wants to prompt the user to
select a project, but limit the selection to projects under a particular
directory.
For example if I have a whole bunch of Elisp that's on my load-path
under, say, ~/.emacs.d/elpa/, I could write a function which will bind
project-prompter-predicate to filter out all other projects. So then I
have a command which is "switch to the source of one of my ELPA packages".
I can also imagine something which filters the selection by forge URI.
So if all my work projects are on a private gitlab instance, I could
write a command which would allow me to select only from my work
projects by matching on the configured remote URI and filtering out
projects on other kinds of remote.
I can imagine something with active nix-envs or something too.
Do you find these examples compelling?
> Questions about implementation:
>
> Will 'project-known-project-roots' use (and be affected by) that predicate?
I don't think so, because that's not an interactive function, and so its
caller can apply a predicate to the return value if wanted.
> Could someone set it up one day and then later see a project-list entry stay
> around in the file but never come up in the prompt, or never be cleared by
> project-forget-zombie-projects?
That could happen if someone gives project-prompter-predicate a global
value, yeah. I don't think you'd want to do that, though -- I was
thinking it'd be a defvar not a defcustom.
> Also IIUC if we consider the "other-working-trees API" approach, I guess it
> wouldn't exactly fit as a solution, because we'd want to substitute the full
> list instead of filtering. (Is that right?) Then an alternative could be just
> a separate user option for the prompter function here.
I don't think there is an inherent clash here. The predicate would just
be (lambda (p) (member p working-trees)) where working-trees is the
result of having called known-other-working-trees.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 30 Jul 2025 12:42:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 79024 <at> debbugs.gnu.org (full text, mbox):
On 30/07/2025 14:00, Sean Whitton wrote:
>> Ideally we should be able to think of some other usage scenarios as well, not
>> just from this worktree feature. Maybe add them to the docstring.
>
> Right. I can most readily imagine code that wants to prompt the user to
> select a project, but limit the selection to projects under a particular
> directory.
>
> For example if I have a whole bunch of Elisp that's on my load-path
> under, say, ~/.emacs.d/elpa/, I could write a function which will bind
> project-prompter-predicate to filter out all other projects. So then I
> have a command which is "switch to the source of one of my ELPA packages".
>
> I can also imagine something which filters the selection by forge URI.
> So if all my work projects are on a private gitlab instance, I could
> write a command which would allow me to select only from my work
> projects by matching on the configured remote URI and filtering out
> projects on other kinds of remote.
>
> I can imagine something with active nix-envs or something too.
>
> Do you find these examples compelling?
They are pretty solid, thanks. Please go ahead.
>> Questions about implementation:
>>
>> Will 'project-known-project-roots' use (and be affected by) that predicate?
>
> I don't think so, because that's not an interactive function, and so its
> caller can apply a predicate to the return value if wanted.
All right.
>> Also IIUC if we consider the "other-working-trees API" approach, I guess it
>> wouldn't exactly fit as a solution, because we'd want to substitute the full
>> list instead of filtering. (Is that right?) Then an alternative could be just
>> a separate user option for the prompter function here.
>
> I don't think there is an inherent clash here. The predicate would just
> be (lambda (p) (member p working-trees)) where working-trees is the
> result of having called known-other-working-trees.
Could be a bit less efficient than just substituting a list. Not sure if
noticeable.
Also, this way we could miss worktrees previously created outside of
Emacs, and not registered in the project history yet. Again, not sure if
it's critical.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Mon, 04 Aug 2025 09:59:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
On Mon 28 Jul 2025 at 08:55pm +01, Sean Whitton wrote:
> Okay, based on adding some tracing to vc-git-command and vc-git--call,
> and inserting 'mv' and 'cd' commands to correspond to other things the
> test does, this is what I have for you:
Mattias sent a fix which may resolve at least the failures you were
seeing on Windows; I just installed it.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Mon, 04 Aug 2025 20:10:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 30 Jul 2025 at 03:41pm +03, Dmitry Gutov wrote:
> On 30/07/2025 14:00, Sean Whitton wrote:
>
>>> Ideally we should be able to think of some other usage scenarios as well, not
>>> just from this worktree feature. Maybe add them to the docstring.
>> Right. I can most readily imagine code that wants to prompt the user to
>> select a project, but limit the selection to projects under a particular
>> directory.
>> For example if I have a whole bunch of Elisp that's on my load-path
>> under, say, ~/.emacs.d/elpa/, I could write a function which will bind
>> project-prompter-predicate to filter out all other projects. So then I
>> have a command which is "switch to the source of one of my ELPA packages".
>> I can also imagine something which filters the selection by forge URI.
>> So if all my work projects are on a private gitlab instance, I could
>> write a command which would allow me to select only from my work
>> projects by matching on the configured remote URI and filtering out
>> projects on other kinds of remote.
>> I can imagine something with active nix-envs or something too.
>> Do you find these examples compelling?
>
> They are pretty solid, thanks. Please go ahead.
I'd previously proposed a variable, project-prompter-predicate, which
Lisp code would bind around calls to prompter-prompter.
But I see that the API for project-prompter has already been changed in
Emacs 31 to add a new optional PROMPT argument. So I've gone with
adding two additional optional arguments instead of adding a new
variable.
>>> Also IIUC if we consider the "other-working-trees API" approach, I guess it
>>> wouldn't exactly fit as a solution, because we'd want to substitute the full
>>> list instead of filtering. (Is that right?) Then an alternative could be just
>>> a separate user option for the prompter function here.
>> I don't think there is an inherent clash here. The predicate would just
>> be (lambda (p) (member p working-trees)) where working-trees is the
>> result of having called known-other-working-trees.
>
> Could be a bit less efficient than just substituting a list. Not sure if
> noticeable.
Yeah. We'll see.
> Also, this way we could miss worktrees previously created outside of Emacs,
> and not registered in the project history yet. Again, not sure if it's
> critical.
This problem is unavoidable for Mercurial.
For Git I've added a loop to vc--prompt-other-working-tree to call
project-remember-project on the possibilities.
This going back and forth between VC and project has become a bit
convoluted but I think nicely serves the various needs we've identified.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 06 Aug 2025 02:12:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hi!
On 04/08/2025 23:09, Sean Whitton wrote:
>> They are pretty solid, thanks. Please go ahead.
>
> I'd previously proposed a variable, project-prompter-predicate, which
> Lisp code would bind around calls to prompter-prompter.
>
> But I see that the API for project-prompter has already been changed in
> Emacs 31 to add a new optional PROMPT argument. So I've gone with
> adding two additional optional arguments instead of adding a new
> variable.
Unexpected, but looks reasonable.
>> Also, this way we could miss worktrees previously created outside of Emacs,
>> and not registered in the project history yet. Again, not sure if it's
>> critical.
>
> This problem is unavoidable for Mercurial.
>
> For Git I've added a loop to vc--prompt-other-working-tree to call
> project-remember-project on the possibilities.
>
> This going back and forth between VC and project has become a bit
> convoluted but I think nicely serves the various needs we've identified.
Nice to see we've avoided using the "private" parts of the package, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 10:51:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Mon, 28 Jul 2025 20:55:32 +0100
>
> > Please show the Git commands we issue during this test, and I will try
> > running them from the shell to see what's going on and why.
>
> Okay, based on adding some tracing to vc-git-command and vc-git--call,
> and inserting 'mv' and 'cd' commands to correspond to other things the
> test does, this is what I have for you:
See the results below, sorry for a long delay. Where I show nothing
after a command it means the command seemed to have succeeded.
> mkdir first
> cd first
> git init
> # create 'foo'
> git --no-pager ls-files -c -z -- foo
> git --no-pager ls-tree --name-only -z HEAD -- foo
This fails:
fatal: Not a valid object name HEAD
> git update-index --add -- foo
> git --no-pager ls-files -c -z -- foo
> git --no-pager status --porcelain -z --untracked-files --ignored -- foo
> git --no-pager rev-parse HEAD
This also fails:
HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
> git --no-pager symbolic-ref HEAD
> git commit -F c:/Users/... --only -- foo # make a commit msg temp file
> git --no-pager rev-parse HEAD
> git for-each-ref --format=%(refname) -- nil
This fails:
bash: syntax error near unexpected token `('
> git worktree add --detach ../second/
> git worktree prune
> git worktree list --porcelain -z
This fails:
error: unknown switch `z'
usage: git worktree add [<options>] <path> [<branch>]
or: git worktree list [<options>]
or: git worktree lock [<options>] <path>
or: git worktree prune [<options>]
or: git worktree unlock <path>
--porcelain machine-readable output
(All the other "list --porcelain -z" commands fail as well. They do
succeed if used without -z.)
> cd ../second
> git worktree prune
> git worktree list --porcelain -z
> cd ../first
> mv ../second ../third
> git worktree repair
This fails:
fatal: Not a git repository: D:/gnu/git/first/.git/worktrees/second
> git worktree prune
Likewise.
> git worktree list --porcelain -z
Likewise.
> cd ../third
> mv ../first ../second
> git worktree repair
Likewise.
> git worktree prune
Likewise.
> git worktree list --porcelain -z
Likewise.
> mv ../second ../first
> git worktree repair
Fails:
fatal: Not a git repository: D:/gnu/git/first/.git/worktrees/second
> cd ../first
> git update-index --refresh
> git --no-pager rev-parse --verify HEAD
> git diff-index --relative -z -M HEAD --
> git ls-files -z -d --
> git ls-files -z -u --
> git ls-files -z -o --exclude-standard --
> git worktree remove -f ../third/
This fails:
usage: git worktree add [<options>] <path> [<branch>]
or: git worktree list [<options>]
or: git worktree lock [<options>] <path>
or: git worktree prune [<options>]
or: git worktree unlock <path>
Does this provide useful info about the failure reason(s)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 10:51:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Mon, 04 Aug 2025 10:58:02 +0100
>
> Hello Eli,
>
> On Mon 28 Jul 2025 at 08:55pm +01, Sean Whitton wrote:
>
> > Okay, based on adding some tracing to vc-git-command and vc-git--call,
> > and inserting 'mv' and 'cd' commands to correspond to other things the
> > test does, this is what I have for you:
>
> Mattias sent a fix which may resolve at least the failures you were
> seeing on Windows; I just installed it.
The tests still fail in the same way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 11:23:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 15 Jul 2025 at 12:50pm +01, Sean Whitton wrote:
> 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.
Just to note that all the features discussed in this bug are now
implemented, so once the test failures have been resolved we can close
it.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 12:27:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
Thanks, this helps in a few ways. I think that your git doesn't support
any of the 'repair', 'move' and 'remove' subcommands of git-worktree.
We can do without 'git worktree remove'. I've changed that on master.
I don't think that vc-git-move-working-tree is possible without either
of 'move' or 'repair', unless we start manually modifying things inside
.git, which as discussed elsewhere in the bug is not a good idea.
So I've added a guard to the tests to not try the vc-move-working-tree
tests with older Git. If the tests still fail, please show me the
output and I'll try to determine where they're failing and possibly send
you a new list of commands.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 12:42:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sun, 10 Aug 2025 13:26:20 +0100
>
> Thanks, this helps in a few ways. I think that your git doesn't support
> any of the 'repair', 'move' and 'remove' subcommands of git-worktree.
>
> We can do without 'git worktree remove'. I've changed that on master.
>
> I don't think that vc-git-move-working-tree is possible without either
> of 'move' or 'repair', unless we start manually modifying things inside
> .git, which as discussed elsewhere in the bug is not a good idea.
What do we need "move" and "repair" for?
> So I've added a guard to the tests to not try the vc-move-working-tree
> tests with older Git.
Not to run them at all? Does it mean that worktrees will be
unavailable in VC in that case?
> If the tests still fail, please show me the
> output and I'll try to determine where they're failing and possibly send
> you a new list of commands.
vc-test-git07-other-working-trees still fails, and it fails while
committing:
Test vc-test-git07-other-working-trees condition:
(error
"Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msgWZPFOT --only -- foo")
What is special about invoking "git commit" from this test? Because
committing generally does work in the other tests.
vc-test-hg07-other-working-trees also fails:
Test vc-test-hg07-other-working-trees condition:
(error
"Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -m Testing other working trees\n\nTesting other working trees\n foo")
but this is because Windows doesn't support newlines in command lines
(we need to use a file, as with Git).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sun, 10 Aug 2025 13:32:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sun, 10 Aug 2025 15:41:13 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> vc-test-git07-other-working-trees still fails, and it fails while
> committing:
>
> Test vc-test-git07-other-working-trees condition:
> (error
> "Failed (status 128): git --no-pager commit -F c:/Users/EliZ/AppData/Local/Temp/git-msgWZPFOT --only -- foo")
After some tinkering, my conclusion is that "git worktree" is too
buggy in my version of Git, so it isn't worth our while to keep
wasting time on this. Maybe add a version check to skip the test is
Git is too old (which version of Git has complete enough
implementation of worktrees?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 12 Aug 2025 13:16:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 10 Aug 2025 at 04:31pm +03, Eli Zaretskii wrote:
> After some tinkering, my conclusion is that "git worktree" is too
> buggy in my version of Git, so it isn't worth our while to keep
> wasting time on this. Maybe add a version check to skip the test is
> Git is too old
Okay. I've now done that.
> (which version of Git has complete enough implementation of
> worktrees?).
2.17, I think.
The remaining thing for this bug is fixing Mercurial committing.
You wrote:
> I don't think it matters with Mercurial, and it can never do any harm
> to use Unix EOLs, I think.
>
> A more important question is the encoding: does hg expect the commit
> log messages to be in UTF-8, or does it not care, or something else?
I wrote:
> <https://wiki.mercurial-scm.org/EncodingStrategy#UTF-8_strings> makes it
> sound like the file is assumed to be in the local encoding and then gets
> converted. However, that page has not been updated for ten years.
>
> There is an option --encoding that one can pass. It defaults to utf-8.
> That makes it seem like we could write out the commit message in UTF-8
> and know it'll be okay.
Do you agree with the plan? That is, always use Unix line endings,
write out the commit message in UTF-8. So the only thing that changes
is going via a file. I should be able to write some tests to assert
this is fine on Windows, which you can run.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 12 Aug 2025 13:23:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Tue, 12 Aug 2025 14:15:17 +0100
>
> The remaining thing for this bug is fixing Mercurial committing.
>
> You wrote:
>
> > I don't think it matters with Mercurial, and it can never do any harm
> > to use Unix EOLs, I think.
> >
> > A more important question is the encoding: does hg expect the commit
> > log messages to be in UTF-8, or does it not care, or something else?
>
> I wrote:
>
> > <https://wiki.mercurial-scm.org/EncodingStrategy#UTF-8_strings> makes it
> > sound like the file is assumed to be in the local encoding and then gets
> > converted. However, that page has not been updated for ten years.
> >
> > There is an option --encoding that one can pass. It defaults to utf-8.
> > That makes it seem like we could write out the commit message in UTF-8
> > and know it'll be okay.
>
> Do you agree with the plan? That is, always use Unix line endings,
> write out the commit message in UTF-8. So the only thing that changes
> is going via a file. I should be able to write some tests to assert
> this is fine on Windows, which you can run.
Yes, agreed. My only comment is that perhaps we should introduce
vc-hg-commits-coding-system, similar to vc-git-commits-coding-system,
by default 'utf-8', and use it with the --encoding switch. But that
could be added later.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Tue, 12 Aug 2025 19:49:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 12 Aug 2025 at 04:22pm +03, Eli Zaretskii wrote:
> Yes, agreed. My only comment is that perhaps we should introduce
> vc-hg-commits-coding-system, similar to vc-git-commits-coding-system,
> by default 'utf-8', and use it with the --encoding switch. But that
> could be added later.
Thanks.
Reading #23076, it is not clear to me why you implemented both: encoding
command line arguments using the system code page, and passing the
commit message through a file.
Your message to the bug first proposing these fixes suggests choosing
between them. But we have both. Can you explain?
Another question would be: do we need both for Mercurial, or is passing
the commit message via a file sufficient?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Wed, 13 Aug 2025 11:18:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Tue, 12 Aug 2025 20:47:49 +0100
>
> Reading #23076, it is not clear to me why you implemented both: encoding
> command line arguments using the system code page, and passing the
> commit message through a file.
>
> Your message to the bug first proposing these fixes suggests choosing
> between them. But we have both. Can you explain?
It is impossible on Windows to use anything but the system codepage
for encoding command-line arguments of Emacs subprocesses. At least
not without some serious changes in how Emacs on Windows supports
sub-processes. So, since Git prefers UTF-8 as encoding of log
messages, we cannot use that encoding for command-line arguments,
because most Windows users don't set their system codepage to UTF-8
(UTF-8 is still in diapers on Windows and produces some subtle
problems and unexpected failures). With the log message written to a
file, the problem with command-line arguments is smaller, since the
actual text is in the file, but the temporary file's name could still
include non-ASCII characters (e.g., if the user's name includes them).
So we need to encode both, and each one needs to use what will usually
be a different encoding, for the reasons explained above.
> Another question would be: do we need both for Mercurial, or is passing
> the commit message via a file sufficient?
I think we need the same for Mercurial, for the same reasons.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 12:28:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 79024 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Wed 13 Aug 2025 at 02:17pm +03, Eli Zaretskii wrote:
> but the temporary file's name could still include non-ASCII characters
> (e.g., if the user's name includes them).
This is the point I was missing, thanks.
Could you test the attached, please?
I've also realised that vc-git-modify-change-comment needs the command
line argument encoding, which I'll fix separately.
--
Sean Whitton
[0001-lisp-vc-vc-hg.el-vc-hg-checkin-Fix-on-MS-Windows-bug.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 12:45:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Thu, 14 Aug 2025 13:26:44 +0100
>
> Could you test the attached, please?
It didn't apply for some reason, so I patched manually.
The vc-test-hg07-other-working-trees test still fails, but in a
different place now:
Test vc-test-hg07-other-working-trees condition:
(error
"Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -A -l c:/Users/EliZ/AppData/Local/Temp/hg-msgjR8Sup foo")
Any ideas?
> + (when msg-file
> + (write-region (car args) nil msg-file))
Shouldn't we bind coding-system-for-write to 'utf-8' here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 13:44:02 GMT)
Full text and
rfc822 format available.
Message #172 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 14 Aug 2025 at 03:44pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
>> Date: Thu, 14 Aug 2025 13:26:44 +0100
>>
>> Could you test the attached, please?
>
> It didn't apply for some reason, so I patched manually.
>
> The vc-test-hg07-other-working-trees test still fails, but in a
> different place now:
>
> Test vc-test-hg07-other-working-trees condition:
> (error
> "Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -A -l c:/Users/EliZ/AppData/Local/Temp/hg-msgjR8Sup foo")
>
> Any ideas?
Hmm, I recently changed vc-do-command to print command output for
failing commands. I assume there's nothing showing up?
Is it possible that your version of Mercurial lacks one of the -A or -l
options? I think we established that you do have the share extension,
though maybe you don't?
I would suggest trying this manually something like this (translated to
Windows speak)
mkdir foo
cd foo
hg init
echo foo >bar
hg add bar
echo msg >../tmp
hg --config ui.report_untrusted=0 --config=extensions.share= commit
-A -l ../tmp bar
>> + (when msg-file
>> + (write-region (car args) nil msg-file))
>
> Shouldn't we bind coding-system-for-write to 'utf-8' here?
Yes, thanks, done locally.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 14:04:01 GMT)
Full text and
rfc822 format available.
Message #175 received at 79024 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello again Eli,
Do you know of any reason we couldn't refactor things in vc-git.el like
this? It would reduce complexity a fair bit.
--
Sean Whitton
[0001-Refactor-binding-coding-system-for-write-for-command.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 15:11:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Thu, 14 Aug 2025 14:43:10 +0100
>
> > The vc-test-hg07-other-working-trees test still fails, but in a
> > different place now:
> >
> > Test vc-test-hg07-other-working-trees condition:
> > (error
> > "Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -A -l c:/Users/EliZ/AppData/Local/Temp/hg-msgjR8Sup foo")
> >
> > Any ideas?
>
> Hmm, I recently changed vc-do-command to print command output for
> failing commands. I assume there's nothing showing up?
Do you mean this:
Checking in foo...
abort: no username supplied
(use 'hg config --edit' to set your username)
> Is it possible that your version of Mercurial lacks one of the -A or -l
> options?
Doesn't seem so, see below.
> I think we established that you do have the share extension,
> though maybe you don't?
Yes, I think so.
> I would suggest trying this manually something like this (translated to
> Windows speak)
>
> mkdir foo
> cd foo
> hg init
> echo foo >bar
> hg add bar
> echo msg >../tmp
> hg --config ui.report_untrusted=0 --config=extensions.share= commit
> -A -l ../tmp bar
This works here, and the last command exits with zero status. Does
the above really faithfully reproduces what the test does?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Thu, 14 Aug 2025 15:31:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Thu, 14 Aug 2025 15:03:37 +0100
>
> Do you know of any reason we couldn't refactor things in vc-git.el like
> this? It would reduce complexity a fair bit.
The problem here is that coding-system-for-write is used for two
purposes: (1) to encode the command-line arguments of a program we are
about to run, and (2) to encode any text we send to the program. And
on Windows we must use two different encodings: command-line arguments
must be encoded with the system codepage, whereas Git prefers its
input and output to be encoded in UTF-8.
Binding coding-system-for-write to locale-coding-system in
vc-git-command basically overrides any encoding forced by the callers,
including by users (if the type "C-x RET c SOMETHING RET" when
invoking VC commands).
So unfortunately, I think this complexity is needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 16 Aug 2025 11:47:02 GMT)
Full text and
rfc822 format available.
Message #184 received at 79024 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
On Thu 14 Aug 2025 at 06:10pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
>> Date: Thu, 14 Aug 2025 14:43:10 +0100
>>
>> > The vc-test-hg07-other-working-trees test still fails, but in a
>> > different place now:
>> >
>> > Test vc-test-hg07-other-working-trees condition:
>> > (error
>> > "Failed (status 255): hg --config ui.report_untrusted=0 --config=extensions.share= commit -A -l c:/Users/EliZ/AppData/Local/Temp/hg-msgjR8Sup foo")
>> >
>> > Any ideas?
>>
>> Hmm, I recently changed vc-do-command to print command output for
>> failing commands. I assume there's nothing showing up?
>
> Do you mean this:
>
> Checking in foo...
> abort: no username supplied
> (use 'hg config --edit' to set your username)
Looks like the problem is determining the committer identity.
I think the attached patch will fix this. I've tested it locally and it
does result in the test commits having the john <at> doe.ee identity.
Could you test it on Windows? Thanks.
>> I would suggest trying this manually something like this (translated to
>> Windows speak)
>>
>> mkdir foo
>> cd foo
>> hg init
>> echo foo >bar
>> hg add bar
>> echo msg >../tmp
>> hg --config ui.report_untrusted=0 --config=extensions.share= commit
>> -A -l ../tmp bar
>
> This works here, and the last command exits with zero status. Does
> the above really faithfully reproduces what the test does?
It reproduces it in terms of commands but I guess that hg's identity
autodetection works differently from the test's temporary directory than
it does from the more ordinary directory where you tried these commands.
--
Sean Whitton
[0001-vc-test-with-author-identity-Handle-Mercurial.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 16 Aug 2025 11:57:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 14 Aug 2025 at 06:30pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
>> Date: Thu, 14 Aug 2025 15:03:37 +0100
>>
>> Do you know of any reason we couldn't refactor things in vc-git.el like
>> this? It would reduce complexity a fair bit.
>
> The problem here is that coding-system-for-write is used for two
> purposes: (1) to encode the command-line arguments of a program we are
> about to run, and (2) to encode any text we send to the program. And
> on Windows we must use two different encodings: command-line arguments
> must be encoded with the system codepage, whereas Git prefers its
> input and output to be encoded in UTF-8.
>
> Binding coding-system-for-write to locale-coding-system in
> vc-git-command basically overrides any encoding forced by the callers,
> including by users (if the type "C-x RET c SOMETHING RET" when
> invoking VC commands).
>
> So unfortunately, I think this complexity is needed.
Thanks. We *are* overriding the user, as described, in vc-git-checkin
and vc-git-modify-change-comment, but we have to do so there. But we
should limit how much we do that. I'll add to the comments.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 16 Aug 2025 12:13:01 GMT)
Full text and
rfc822 format available.
Message #190 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sat, 16 Aug 2025 12:46:04 +0100
>
> > Checking in foo...
> > abort: no username supplied
> > (use 'hg config --edit' to set your username)
>
> Looks like the problem is determining the committer identity.
>
> I think the attached patch will fix this. I've tested it locally and it
> does result in the test commits having the john <at> doe.ee identity.
> Could you test it on Windows? Thanks.
I guess I should test this together with the previous patch you sent
for vc-hg.el?
I still get a failure in that test, but a different one now:
Test vc-test-hg07-other-working-trees condition:
(ert-test-failed
((should (equal (list second) (vc-call-backend backend ...))) :form
(equal ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/")
nil)
:value nil :explanation
(different-types
("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/") nil)))
FAILED 32/56 vc-test-hg07-other-working-trees (0.592570 sec) at lisp/vc/vc-tests/vc-tests.el:1
HTH
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 16 Aug 2025 13:24:01 GMT)
Full text and
rfc822 format available.
Message #193 received at 79024 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 16 Aug 2025 at 03:12pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
>> Date: Sat, 16 Aug 2025 12:46:04 +0100
>>
>> > Checking in foo...
>> > abort: no username supplied
>> > (use 'hg config --edit' to set your username)
>>
>> Looks like the problem is determining the committer identity.
>>
>> I think the attached patch will fix this. I've tested it locally and it
>> does result in the test commits having the john <at> doe.ee identity.
>> Could you test it on Windows? Thanks.
>
> I guess I should test this together with the previous patch you sent
> for vc-hg.el?
Right.
> I still get a failure in that test, but a different one now:
>
> Test vc-test-hg07-other-working-trees condition:
> (ert-test-failed
> ((should (equal (list second) (vc-call-backend backend ...))) :form
> (equal ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/")
> nil)
> :value nil :explanation
> (different-types
> ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/") nil)))
> FAILED 32/56 vc-test-hg07-other-working-trees (0.592570 sec) at lisp/vc/vc-tests/vc-tests.el:1
>
> HTH
It does, thanks. So, looks like my implementation of the coding systems
hack for Mercurial is fine. So I've installed that.
Then I think what we have is an actual bug instead of just a test suite
problem. One or both of vc-hg-add-working-tree and
vc-hg-known-other-working-trees don't work on Windows. I suspect that
it is the latter.
Could you take a glance over vc-hg-known-other-working-trees and see if
perhaps it is making obviously invalid assumptions about Windows paths?
If that doesn't reveal anything, I'd like to ask you to try manually
creating a new working tree, from Emacs, to rule out any problems with
vc-hg-add-working-tree. Something like this:
- M-x mkdir RET ~/foo RET
- C-x C-f ~/foo/bar RET blah C-x C-s
- C-x v v
+ it should prompt for the backend, choose Hg
- C-x v v blahblah C-c C-c
+ checks in the file
- C-x v w c foo2 RET
Now check that there is a new tree foo/../foo2/ (or wherever you put it)
and that the file foo/../foo2/.hg/sharedpath contains the path of the
original foo. If there is then we can be pretty sure the problem is
vc-hg-known-other-working-trees.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79024; Package
emacs.
(Sat, 16 Aug 2025 14:04:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 79024 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
> Date: Sat, 16 Aug 2025 14:22:52 +0100
>
> > Test vc-test-hg07-other-working-trees condition:
> > (ert-test-failed
> > ((should (equal (list second) (vc-call-backend backend ...))) :form
> > (equal ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/")
> > nil)
> > :value nil :explanation
> > (different-types
> > ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/") nil)))
> > FAILED 32/56 vc-test-hg07-other-working-trees (0.592570 sec) at lisp/vc/vc-tests/vc-tests.el:1
> >
> > HTH
>
> It does, thanks. So, looks like my implementation of the coding systems
> hack for Mercurial is fine. So I've installed that.
>
> Then I think what we have is an actual bug instead of just a test suite
> problem. One or both of vc-hg-add-working-tree and
> vc-hg-known-other-working-trees don't work on Windows. I suspect that
> it is the latter.
>
> Could you take a glance over vc-hg-known-other-working-trees and see if
> perhaps it is making obviously invalid assumptions about Windows paths?
>
> If that doesn't reveal anything, I'd like to ask you to try manually
> creating a new working tree, from Emacs, to rule out any problems with
> vc-hg-add-working-tree. Something like this:
>
> - M-x mkdir RET ~/foo RET
> - C-x C-f ~/foo/bar RET blah C-x C-s
> - C-x v v
> + it should prompt for the backend, choose Hg
> - C-x v v blahblah C-c C-c
> + checks in the file
> - C-x v w c foo2 RET
>
> Now check that there is a new tree foo/../foo2/ (or wherever you put it)
> and that the file foo/../foo2/.hg/sharedpath contains the path of the
> original foo. If there is then we can be pretty sure the problem is
> vc-hg-known-other-working-trees.
Thanks, I hope the problem and its solution are clear from the patch
below. With that, the test now passes.
I hope using expand-file-name doesn't slow this down too much. (I
considered using file-equal-p, but the results are undefined if one or
both of the files don't exist.)
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index e9095b7..564cb00 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1738,7 +1738,10 @@ vc-hg-known-other-working-trees
(if (file-exists-p our-sp)
(with-temp-buffer
(insert-file-contents-literally our-sp)
- (setq our-store (string-trim (buffer-string)))
+ ;; On MS-Windows, ".hg/sharedpath" gives file names with
+ ;; backslashes; expand-file-name normalizes that to forward
+ ;; slashes, needed for 'equal' comparison below.
+ (setq our-store (expand-file-name (string-trim (buffer-string))))
(push (abbreviate-file-name (file-name-directory our-store))
shares))
(setq our-store (expand-file-name ".hg" our-root)))
@@ -1748,7 +1751,9 @@ vc-hg-known-other-working-trees
((file-exists-p sp)))
(with-temp-buffer
(insert-file-contents-literally sp)
- (when (equal our-store (buffer-string))
+ (when (equal our-store
+ ;; See above why we use expand-file-name
+ (expand-file-name (string-trim (buffer-string))))
(push root shares)))))
shares))
Reply sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
You have taken responsibility.
(Sat, 16 Aug 2025 18:42:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
bug acknowledged by developer.
(Sat, 16 Aug 2025 18:42:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 79024-done <at> debbugs.gnu.org (full text, mbox):
Hello,
Excellent, thanks. With your patch applied the tests pass here too.
Installed and closing the bug.
--
Sean Whitton
Reply sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
You have taken responsibility.
(Sat, 16 Aug 2025 18:42:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
bug acknowledged by developer.
(Sat, 16 Aug 2025 18:42:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 14 Sep 2025 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.