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 20:18:12 +0200

> Cc: 51497 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 8 Nov 2021 20:30:55 +0300
> 
> >> 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.

So what would you suggest as the way forward, for both emacs-28 and
the master branches (the 2 solutions could be different)?  Do you
still prefer to go with your original patch for emacs-28?

Previous Next

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