Re: describe fails on tagless branch

[Andy Parkins <andyparkins@gmail.com>]

On Wednesday 2007 February 07 09:58, Junio C Hamano wrote:

> > 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