GNU bug report logs - #57777
28.2; `vc-dir' picks incorrect backend.

Previous Next

Package: emacs;

Reported by: Mike Woolley <mike <at> bulsara.com>

Date: Tue, 13 Sep 2022 16:31:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.2

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Mike Woolley <mike <at> bulsara.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57777 <at> debbugs.gnu.org
Subject: Re: bug#57777: 28.2; `vc-dir' picks incorrect backend.
Date: Thu, 15 Sep 2022 15:53:32 +0100
[Message part 1 (text/plain, inline)]
Thanks for looking at this Lars.

The steps you tried also work correctly for me, so clearly the problem is a bit more specific than I initially thought!

I stepped through `vc-responsible-backend’ in the debugger when executing `vc-dir’ on one of the directories where I have this problem (my home directory in the following example).
This bit of code:

 (vc-call-backend backend 'responsible-p file)

returns "~/“ for the Git backend, but "/Users/mike/“ for the CVS backend.

Further down, this next bit of code looks for the longest directory string in an attempt to find the deepest subdirectory:

  ;; Several roots; we seem to have one vc inside another's
  ;; directory.  Choose the most specific.
  (caar (sort dirs (lambda (d1 d2)
                     (< (length (cdr d2)) (length (cdr d1))))))))

Which explains why it picks the CVS backend, because "/Users/mike/“ is longer than "~/“ 😊

So in other words, the missing step from my instructions is the directory has to be under the user’s home directory.

I would have thought the fix would be either to make `responsible-p’ return the same string or expand the “~” before executing the length comparison above.

Thanks,
Mike

> On 14 Sep 2022, at 15:43, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
>>> I'm unable to reproduce this problem with Emacs 28.2 (or the current
>>> trunk).
>> 
>> Sorry; I was testing in the wrong checkout -- I'm now rebuilding the
>> real emacs-28.2 release and will re-test.
> 
> I've now redone the tests, but I'm still not able to reproduce the
> problem.

[Message part 2 (text/html, inline)]

This bug report was last modified 2 years and 250 days ago.

Previous Next


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