Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: describe fails on tagless branch

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:53

Andy Parkins [off-list ref] writes:
On Wednesday 2007 February 07 02:14, Junio C Hamano wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help