|
From: | Dmitry Gutov |
Subject: | bug#51497: 29.0.50; (vc-print-log) broken over TRAMP |
Date: | Mon, 8 Nov 2021 20:30:55 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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 +0300Why 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.
[Prev in Thread] | Current Thread | [Next in Thread] |