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

[Dmitry Gutov]

On 08.11.2021 15:49, Eli Zaretskii wrote:
> > 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.

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.