On Sunday 10 June 2007, Junio C Hamano wrote: > 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. It already does? Or are you proposing this? Right now the code doesn't enforce anything like this, AFAICS... > 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. I have nothing against limiting keywords to fairly small set, say alphanumerics plus a couple of "safe" symbols. It just didn't make sense to do this when I made the patch without doing it to the tag name at the same time, and I'm not sure what that restricted set should be, so I held off on it. Feel free to fix. > 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. Yes, this is what I'm thinking; using keywords to filter tag objects in various settings. Haven't thought much about the syntax yet, but as it would have to work on the command-line (possibly together with the other weird characters git uses for specifying revisions), I imagine a character set similar to the one for tag names should be good. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
