Re: describe fails on tagless branch
From: Andy Parkins <hidden>
Date: 2016-06-15 22:42:53
On Wednesday 2007 February 07 09:58, Junio C Hamano wrote:
quoted
Agreed - the "nearest tag" mode (--abbrev=0) would be broken in that it git-describe would return a tag that doesn't exist."describe" is about giving a short name for public communication to a commit in terms of well known tags. If there is no tag, then it is natural to say that the commit is indescribable. In the case of "git-describe --abbrev=0 $indescribable", it could return an empty string, since there is no nearest tag after all. But that would not apply to non --abbrev=0 case.
Absolutely. I agree entirely. The /only/ valid thing to return when git-describe is asked "what is the nearest tag" when there is no tag is nothing. I don't see how it could be otherwise. If there were a way to return NULL instead of "" then I'd vote for that (actually we could argue that the return code tells you it's NULL); however that's moot since it's not possible to have empty tags. git-describe returns an empty string whatever the --abbrev when there is no tag. To my mind it's working perfectly. Every case is both handled and detectable. What more could it do? Slight aside: The only thing that has ever crossed my mind as an improvement to git-describe would be to get at its revision counting mechanism. Just for fun really as I don't think it's that useful in the real world. Wouldn't it be interesting if you could say: $ git-describe --revisions-per-tag HEAD 30% v1.0.0 20% v1.1.0 15% v1.2.0 13% v1.3.0 12% v1.4.0 4% v1.5.0 1% (indescribable) However, I think I'm just being silly :-)
It might not be a bad idea to give '-q' option to make it silent when it fails because the commit is indescribable.
I don't think it's worth it. The "-q" be used only in scripts, and in a script you would do the whole "2> /dev/null || echo 'No tag found'" thing anyway. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com