GNU bug report logs - #51497
29.0.50; (vc-print-log) broken over TRAMP

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lists <at> dima.secretsauce.net, 51497 <at> debbugs.gnu.org, larsi <at> gnus.org,
 wolfgang.scherer <at> gmx.de
Subject: Re: bug#51497: 29.0.50; (vc-print-log) broken over TRAMP
Date: Sun, 7 Nov 2021 01:19:26 +0300

On 06.11.2021 22:52, Eli Zaretskii wrote:
>> Cc: lists <at> dima.secretsauce.net, 51497 <at> debbugs.gnu.org, larsi <at> gnus.org,
>>   wolfgang.scherer <at> gmx.de
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Sat, 6 Nov 2021 22:44:55 +0300
>>
>>> I'm a bit worried by the function relying on the fact that
>>> default-directory is the directory of the repository.  Wouldn't it be
>>> better to explicitly let-bind it inside the function?
>>
>> We could, but notice how most of vc-git-* functions don't bind
>> default-directory, thus relying on its implicit value. It just how VC
>> works: expecting default-directory to have the right value around the calls.
> 
> How certain are you that default-directory has the right value?
> Because if it doesn't, AFAIU all the connection-specific stuff will
> fall apart.

Reasonably, but not 100%. Especially with third-party code which calls 
into VC (it could adapt independently from Emacs releases, though).

We could try to bind default-directory inside vc-git--literal-pathspec, 
but this approach is not 100% reliable either: for all I know, sometimes 
FILE will be a relative name (we even have a file-name-absolute-p check 
inside).

But what's the worst thing that can happen because of this? Suppose some 
caller will leave default-directory at a wrong value. Then 
vc-git--program-version will return the version from a wrong host. And 
some particular command (probably a less popular one) will remain broken 
on remote CentOS 7 machines. That's still an improvement compared to the 
current sutuation.

So I suggest we push the proposed change to emacs-28 and then maybe back 
it out (or modify as necessary) if problems arise.

>>> A (perhaps safer) alternative for emacs-28 would be not to use
>>> :(literal) for remote repositories.  What are the disadvantages of
>>> that?
>>
>> That would mean leaving bug#39452 unfixed on remote hosts.
> 
> Only for files with wildcard characters in their names.  How
> frequently does that happen?  Also, it will be only unsolved in Emacs
> 28.

I've never seen this in practice, but some other categories of users 
might encounter it more often (e.g. science people, who tend to use more 
exotic files names). And when one does see it, it must be very annoying 
to debug.

Previous Next

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