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.
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
Andy Parkins wrote:
quoted
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.
It would be worth for Perl (for gitweb) to be able to use list form of magic
open, without spawning shell (and assorted argument quoting troubles), but
silently.
I think it would be fairly easy to add -q option to git wrapper: it would
simply set die, error and warn routines and no-op (no-write) versions.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git