Junio C Hamano <gitster@xxxxxxxxx> writes: > On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones > <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> That would be workable, I would think. Before attr:VAR=VAL >>> extention, supported pathspec <magic> were only single lowercase-ascii >>> alphabet tokens, so nobody would have used " as a part of magic. So >>> quting with double-quote pair would work. >> >> I was thinking about both ' and ", so that you could do: > > Yes, I understood your suggestion as such. Quoting like shells would work > without breaking backward compatibility for the same reason quoting with > double-quote and backslash only without supporting single-quotes would > work. Having said that, "It would work" does not have to mean "Hence we must do it that way" at all. Quoting character pairs make the parsing and unquoting significantly more complex. As you said, not many people used attributes and pathspec magic, and I do not think those who want to use the new "further limits with attributes" magic, envisioned primarily to be those who want to give classes to submodules, have compelling reason to name their classes with anything but lowercase-ascii-alphabet tokens. So for a practical purposes, I'd rather see Stefan * just implement backquote-blindly-passes-the-next-byte and nothing more elaborate; and * forbid [^-a-z0-9,_] from being used in the value part in the attr:VAR=VAL magic. at least for now, and concentrate more on the other more important parts of the submodule enhancement topic. That way, those who will start using attr:VAR=VAL magic will stick themselves to lowercase-ascii-alphabet tokens for now (simply because an attribut that has the forbidden characters in its value would not be usable with the magic), and we can later extend the magic syntax parser in a backward compatible way to allow paired quotes and other "more convenient" syntax. [Footnote] *1* The reason I prefer to keep the initially allowed value characters narrow is because I envision that something like :(attr:VAR=(<some expression we will come up with later>)) may become necessary, and do not want to promise users that open or close parentheses will forever be taken literally. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html