Junio C Hamano <gitster@xxxxxxxxx> writes: > I also think this illustrates my earlier point. Depending on the > project and the expectation of the users, which tags are good > candidates as anchor points differ. Your example using --match > probably shows a good direction to go in---somehow tell Git which > tags to base the description on, to reject names that the users do > not want. I've used --match only to force git describe to find a better match. > When your project does not mind basing the description on rc tags, > between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if > we would want to say that "the former is not so longer than the > latter, so use that", or what kind of heuristics to employ to reach > that conclusion. Date-based selection (i.e. earliest first) is one > possibility. Tagname-based selection has the issue of having to > configure "whose version numbering convention would you use when > sorting tags, and how you would tell Git that sorting order rule?" IMHO git should select based on topology: the first tag that isn't contained in any other tag still containing the commit in question, only when ambigous it needs to fall back to other criteria. Andreas. -- Andreas Schwab, schwab@xxxxxxxxxxxxxx GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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