bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#51497: 29.0.50; (vc-print-log) broken over TRAMP
Date: Sun, 7 Nov 2021 03:11:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]