bug#51497: 29.0.50; (vc-print-log) broken over TRAMP

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.11.2021 18:51, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: 51497@debbugs.gnu.org, Wolfgang Scherer <wolfgang.scherer@gmx.de>,
>>   Dima Kogan <lists@dima.secretsauce.net>
>> Date: Sat, 6 Nov 2021 16:22:56 +0300
>>
>> On 03.11.2021 15:06, Dmitry Gutov wrote:
>>> Lars, Eli, can we put it in Emacs 28?
>>
>> Ping.
> 
> Sorry for missing the original question.
> 
> 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.

The only current caller of vc-git--program-version (vc-git-state) does 
not either. The backend methods that do, seem to do that with some 
additional purpose (like having default-directory point to the 
repository root, rather than be a random directory inside it).

> 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. Seems like a 
significant disadvantage to me (inconsistent behavior leads to more 
difficult reproduction and reporting of bugs, in particular for those 
who will notice this problem remotely but would not be able to reproduce 
locally). Given that the code complexity added by fixing this bug would 
remain with us, seems more like worst-of-both-worlds kind of situation.

But it would make VC work on remote CentOS 7 hosts again, there's that.