describe fails on tagless branch

try 

  git init
  echo hoi > a
  git add a
  git commit -m 'add a' a
  git describe

this yields

[lilydev@haring t]$ git describe fatal: cannot describe '3b26396bbb5f18580ffd4bc31f70ef0738ec73d6'

I would prefer it if an implicit tag INIT was supposed at the start of the history, so we'd get

  INIT-3b2...

[Cc: git@vger.kernel.org]

Han-Wen Nienhuys wrote:

_Which_ INIT? In git there can be more than one root commit. In git.git repository mainline (maint, master, next and pu branches) has 4 roots (plus three linear independent branches: man, html and todo, each with its own root).

I agree that error description should probably be better: cannot describe _why_.

Jakub Narebski escreveu:

I don't really care, but I would like git-describe to produce something useful in the absence of tags. The -g<SHA-1> already makes the commit uniquely identifiable.

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

Then you would script like this:

	#!/bin/sh
	git describe "$1" 2>/dev/null || git rev-parse --verify "$1"

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

[Cc: git@vger.kernel.org]

Junio C Hamano wrote:

By the way, new git-describe gives us also number of commits since tag, and it would be nice to have number of commits since init... but that can be easily obtained using "git rev-list $1 | wc -l".

I guess that some use git-describe with --abbrev=0 to get closest preceding tag: getting INIT would confuse them.

That said, we could use e.g. INITg2a45ba+10-g4ee2ab

On Wednesday 2007 February 07 02:14, 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.

Andy

Andy Parkins <andyparkins@gmail.com> writes:

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

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

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

Andy Parkins wrote:

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 <jnareb@gmail.com> writes:

You completely missed my point. describe -q would not squelch *all* errors and die()'s, but only the specific "this cannot be described". If you give a non-existent object name on the command line, it _should_ barf loudly.