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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 51497@debbugs.gnu.org, andrewjmoreton@gmail.com
> From: Dmitry Gutov <dgutov@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.  Do we have
valid use cases where only some of the file names need to be treated
as literal?