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: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 51497 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: bug#51497: 29.0.50; (vc-print-log) broken over TRAMP
Date: Mon, 08 Nov 2021 14:49:47 +0200

> 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.  Do we have
valid use cases where only some of the file names need to be treated
as literal?

Previous Next

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