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

From: Dmitry Gutov <[email-masked]>
Date: Sun, 7 Nov 2021 03:11:43 +0300

On 07.11.2021 02:03, Andy Moreton wrote:
> On Sun 07 Nov 2021, Dmitry Gutov wrote:
> 
>> On 07.11.2021 01:11, Andy Moreton wrote:
>>> That workaround is still needed for me. Without that, nothing in vc-git
>>> works in my environment (64bit minw64 build on win10, using cygwin bash
>>> and git together with cygwin-mount.el from emacs wiki).
>>
>> Does that environment also have an old version of Git? Or is there another
>> reason why it's broken?
> 
> I have git 2.33 in cygwin and MSYS2, so git is not old. I'll look at
> this again now that the changes have stablised.

It would have been nice to receive this feedback before the emacs-28 
branch was cut, when we had more freedom to alter the implementation.

>>> While I realise my setup is somewhat non-standard, other users may also
>>> find that the literal pathspec code also misbehaves.
>>
>> I would like to fix it for all users, but debugging would fall on your
>> shoulders, I'm afraid.
> 
> My note was more to warn that adding this to emacs-28 may bring
> problems.

Adding what? The literal pathspec stuff is already there.

> Looking at this again, Trying "C-x v l" for INSTALL in the repo master
> branch gives (rewrapped for clarity):
> 
>    fatal: :(literal)c:/emacs/git/emacs/master/nt/INSTALL:
>    'c:/emacs/git/emacs/master/nt/INSTALL' is outside repository at
>    '/c/emacs/git/emacs/master'
> 
> This appears to be due to the translation between win32 and cygwin
> (posix) filenames.

It might be fixable inside vc-git--literal-pathspec. Is there some other 
more general path conversion function we should use instead of 
'file-local-name' there? A tested patch would help a lot.

Failing that, I think we'll need to change the "literal pathspecs" 
implementation to yet another approach (adding --literl-pathspecs flag 
instead of manipulating file names). It comes with the same general 
drawbacks as the env var (which is used under the hood), but the 
explicit approach of specifying it in every command would avoid the 
problem of my original fix for that bug.