Re: describe fails on tagless branch

From: Junio C Hamano <junkio@cox.net>
Date: Feb 7, 2007, 09:58 UTC
Message-ID: <7vy7na8f2t.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200702070922.57163.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 8 quoted lines

> On Wednesday 2007 February 07 02:14, Junio C Hamano wrote:
>
>> I do not think it a good idea to make "git-describe" itself do
>> the above, as the user of describe may want to fall back on
>> something other than "rev-parse --verify" after ||.
>
> 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.

Really, people should not be afraid to script a few-liner. Who cares if "git describe HEAD" says "can't" in an interactive session? And if you are scripting, and if you want your script to say something usable even for indescribable commits, then you would want to have an easy way to tell if the commit is describable or not. Changing it not to fail like it currently does means the script needs to do something more than just check the return value from describe $? in order to fall back on whatever alternative behaviour it wants to implement.

It might not be a bad idea to give '-q' option to make it silent when it fails because the commit is indescribable.