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 <jack@xxxxxxx> SUSE Labs, CR -- 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