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

Previous Next

Full log

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Wolfgang.Scherer <at> gmx.de, Dmitry Gutov <dgutov <at> yandex.ru>,
 Noam Postavsky <npostavs <at> gmail.com>, 39452 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#39452: [PATCH] vc-git-state fails for filenames with wildcards
Date: Sat, 28 Aug 2021 17:44:35 +0200

On Sat, 28 Aug 2021 17:07:01 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I just discovered that some code I have that uses vc-print-log-internal
>> broke after the literal-pathspecs change; specifically, my code passes a
>> directory name beginning with "~/" to vc-print-log-internal, and this
>> had worked fine till that change, which broke it, and I found I have to
>> wrap the directory name in expand-file-name to make the code work again.
>> Is this expected fallout from that change or was I perhaps misusing
>> vc-print-log-internal and was just lucky that it had worked before?
>
> I think it's reasonable to expect parameters to `vc-print-log-internal'
> to have been expanded first, but that should be documented, at least.

I'm not sure it needs to be documented, it is internal, after all.  I'm
using it because I want a different UI than what vc-print-log provides.
The latter passes the file name to vc-print-log-internal already
expanded; I should have checked that when I decided to use the internal
function.  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.

Steve Berman

Previous Next

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