On Sun, Mar 03, 2013 at 01:15:21PM -0800, Junio C Hamano wrote:
> Greg Price <pr...@mit.edu> writes:
> > It seems to me that "--all" says two things:
> >
> >  (a) allow unannotated (rather than only annotated)
> >
> >  (b) allow refs of any name (rather than only tags)
> >
> > With "--match", particularly because the pattern always refers only to
> > tags, (b) is obliterated, and your proposed semantics are (a) plus a
> > sort of inverse of (b):
> >
> >  (c) allow only refs matching the pattern
> I would think it is more like "only (a), without changing the
> documented semantics of what '--all' and '--match' are by adding (b)
> or (c)".

Perhaps I'm confused somehow?  I believe (a) and (b) together are the
documented semantics of what '--all' is.  And I believe (c), which
contradicts (b) and indeed goes in the opposite direction, is the
documented semantics of what '--match' is.

Certainly we could choose to resolve the conflict by saying that
'--match' overrides '--all', so that '--all' plus '--match' means
(a)+(c).  I believe that's what you suggested.

I think it would be preferable to recognize the conflict and let the
user sort out what they actually mean, because if they (or their
script) gave these options together then I think there's a substantial
likelihood that they are confused or their script is buggy.  If they
mean (a)+(c), they can get it more clearly with '--tag --match'.

> I do not think in the longer term it is wrong per-se to change the
> semantics of "--match" from the documented "Only consider tags
> matching the pattern" to "Only consider refs matching the pattern",
> and such a change can and should be made as a separate patch
> "describe: loosen --match to allow any ref, not just tags" on top of
> the patch I sent which was meant to be bugfix-only.

Yeah, that could be useful.  What form of pattern would you suggest
that the new '--match' accept?  The obvious, and unambiguous, form of
pattern is glob patterns on the full ref name, as with 'for-each-ref'.
Those are a little unwieldy for interactive use, but are perfect for a
script.  And probably 'describe --match' itself already makes the most
sense in a scripted context, as for interactive use one can go into
'gitk' or 'git log --oneline --decorate' or the like and find out the
same information plus more detail.

Particularly when handling both tags and other refs, I can also
imagine wanting to specify a disjunction of several patterns.  So we
might want to accept the option several times cumulatively.

I'd worry about changing the semantics of existing 'describe --match'
invocations in people's scripts, etc.  Perhaps we'd give it a new name
like '--match-ref'.  Or we could say something like, if it starts with
"refs/" it's a pattern on the whole refname, else it's a pattern on
just the tag name, and accept that if someone has a ref called
"refs/tags/refs/foo" and was finding it with 'describe --match' then
that will break until they edit the pattern.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to