On 02/06/16 20:29, Junio C Hamano wrote: > 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. OK, that reasonable. I didn't mean to derail Stefan's development! ATB, Ramsay Jones > > 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