Junio C Hamano <gitster@xxxxxxxxx> writes:
> You did not describe what problem you are trying to solve, but the above
> tells me that the design of this feature has a lot of room to be improved
> to be useful for even a single trivial use scenario I can think of off the
> top of my head.
Having said all that, the biggest problem I have with the approach of this
patch is that it does not decompose the necessary functionalities in a way
that allows combinations of options people naturally would expect from the
description of the feature.
"git tag" can be used to create (-a), delete (-d), show (-l) and verify
(-v). Among these modes, creation has to work on a single tag, so it is a
bit special. But the other three modes could also use the filtering
feature of what "show" supports among themselves.
The mode to show tags (-l) starts from _all_ tags, but limits the output
to those that match given patterns, and the output can further be limited
to the ones that contain a given commit. The verify mode and the delete
mode do not offer this behaviour and require the user to specify exact tag
names. If you are adding "I want to do X on all tags that point at this
object" feature, in which X happens to be "verification" in your case,
don't you think other people would naturally want to use the feature with
X=show instead?
The right first step to do this would be to enhance the "filter" logic so
that it not just lets "--contains", but also "--points-at", be specified.
Once that is done, you could just say:
$ git tag -l --points-at master:README
to list all the tags that point at the blob, and then your original
example becomes:
$ git tag --points-at master:README | xargs git tag -v
It even allows something like this:
$ git tag --points-at master:README 'v1.[0-4].?' |
xargs git tag -v
to work on tags that point at the blob but only those whose names match
the given pattern, i.e. versions from v1.0 series up to v1.4 series but
not later.
After that is done, you could teach the --verify mode to also accept the
patterns, not exact names, so that the above could become:
$ git tag --verify --points-at master:README
$ git tag --verify --points-at master:README 'v1.[0-4].?'
Theoretically, the "start from all and then filter" feature could be
shared also with "delete" mode, but I would not recommend doing so for
safety reasons (i.e. "delete" is destructive). Even so, if somebody does
want to do a bulk delete, it is just a simple matter of:
$ git tag --points-at master:README 'v1.[0-4].?' |
xargs git tag -d
So it is not a big deal if you did not to teach --delete to share the
filtering logic with "show".
For exactly the same reason, --verify mode does not have to share the
logic, either. Not having to use "| xargs" is merely an icing on the cake.
Hmm?
--
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