On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
> So perhaps the rule should be updated to do something like:
>
> - find candidate tags that can be used to "describe --contains"
> the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
>
> - among the candidate tags, cull the ones that contain another
> candidate tag, rejecting v3.5 (not shown) and v9.0;
>
> - among the surviving tags, pick the closest.
I guess all parties agree with the first two points (and actually I would
prefer not to assume anything about tag names and consider v3.4-rc1 as good
as v3.4). Regarding the strategy what to select when there are several
remaining tags after first two steps I would prefer to output all such
tags. As people have mentioned in this thread it varies a lot between
projects what people want to see (and in some cases I can imagine people
really *want* to see all the tags). So printing all such tags would let
them select the desired tag with grep or some more elaborate scripting...
Just a thought.
Honza
--
Jan Kara <j...@suse.cz>
SUSE Labs, CR
--
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
