Johan Herland <johan@xxxxxxxxxxx> writes: > For now, I couldn't find a good reason why the set of allowed characters > for keywords should be smaller than for the tag name. The set of allowed tag names excludes shell metacharacters, primarily to help scripting. I think keywords can share the same reasoning to exclude them. It also excludes '^', '~' and ':', because tag names can be used in revision range expressions (i.e. prefix '^' is the "exclude from the resulting set" operation, postfix "~<number>" is the "Nth generation ancestor" operation) and general SHA-1 expression (i.e. infix ':' is the "find in the tree-ish the object at path" operation). These reasons would not apply to keywords. Having said all of that, I suspect it is premature to talk about keywords, as it is unclear what their intended use is. What kind of operations are useful on them? It does not count that "git cat-file tag" would show "keywords blah" on the header instead of in body. It is not a compelling enough reason to introduce a new header type. grep would work just fine for such a use. On the other hand, for example, if (the syntax is totally made up) we make '::keywords=foo::' expand to set of all tags that have the specified keyword 'foo', and it turns out to be useful to be able to say "git show ::keywords=foo::" instead of listing individual tags, that kind of use case may make it a good reason to add such a new header type. - 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
