GNU bug report logs - #39452
[PATCH] vc-git-state fails for filenames with wildcards

Previous Next

Package: emacs;

Reported by: Wolfgang Scherer <Wolfgang.Scherer <at> gmx.de>

Date: Thu, 6 Feb 2020 14:00:02 UTC

Severity: normal

Tags: patch

Fixed in version 28.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stephen Berman <stephen.berman <at> gmx.net>
Cc: Wolfgang.Scherer <at> gmx.de, Noam Postavsky <npostavs <at> gmail.com>, 39452 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#39452: [PATCH] vc-git-state fails for filenames with wildcards
Date: Sun, 29 Aug 2021 01:19:21 +0300
On 28.08.2021 18:48, Lars Ingebrigtsen wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
> 
>> But I don't see at first glance why the unexpanded file name
>> in the latter worked prior to the literal-pathspecs change but not
>> afterwards.
> 
> Isn't that what that change does -- make git interpret paths literally?
> (So that you can have file names like "~" and "*" in your repo.)

Yes and no: Git never received file names starting with "~" anyway - 
because vc-do-command converted all file names to relative ones.

But a file name starting with ":(literal)..." is not something 
recognized by Emacs, so file-relative-name doesn't work anymore.

If instead of altering file names we switch to the --literal-pathnames 
argument, this problem should go away. But we will return to the 
original concern that "the way git implements it, which
is by setting an environment variable: it affects all subprocesses git
calls, including git-hook scripts which tends to trip people up" 
(quoting Noam).




This bug report was last modified 3 years and 314 days ago.

Previous Next


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