GNU bug report logs - #51497
29.0.50; (vc-print-log) broken over TRAMP

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51497 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: bug#51497: 29.0.50; (vc-print-log) broken over TRAMP
Date: Mon, 8 Nov 2021 20:30:55 +0300

On 08.11.2021 15:49, Eli Zaretskii wrote:
>> Cc: 51497 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Mon, 8 Nov 2021 01:36:18 +0300
>>
>>> Why wasn't --literal-pathspecs used in the first place? what are the
>>> downsides?  IME, using magic file names is always worse, because it
>>> can run afoul of various shells that consider some characters special.
>>
>> It wasn't among the proposed solutions.
>>
>> I went with the env var solution initially (because it required less
>> code and brought fewer -- none -- Git version compatibility problems),
>> but it didn't yield itself as easily to the per-action opt-in as the
>> other proposal (currently installed).
>>
>> But now that I think about it, it would be possible to do this without a
>> new macro, just adding a new variable that default to nil, and set it to
>> t in every backend method that needs it.
> 
> But would that solve our problems for which :(literal) was introduced?
> AFAIU, the difference between that and --literal-pathspecs is that the
> latter is global: it affects all the file names of the Git command,
> while the former can be applied only to some file names.

Both can be used per-command, but indeed it's true: the :(literal) 
syntax can also be used to apply to individual specs only.

>Do we have
> valid use cases where only some of the file names need to be treated
> as literal?

Even though it's plausible, I haven't encountered this particular use 
case so far. Perhaps when we do, we could mix-and-match :(literal) and 
--literal-pathspecs.

Previous Next

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