GNU bug report logs - #79024
31.0.50; Multiple working trees support for VC

Previous Next

Package: emacs;

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.

Full log


Message #103 received at 79024 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Mon, 28 Jul 2025 20:55:32 +0100
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




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.