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

From: Dmitry Gutov <[email-masked]>
Date: Mon, 8 Nov 2021 20:30:55 +0300

On 08.11.2021 15:49, Eli Zaretskii wrote:
>> Cc: [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>> 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.