describe fails on tagless branch

describe fails on tagless branch

[Han-Wen Nienhuys]

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


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: describe fails on tagless branch

[Jakub Narebski]

[Cc: git@vger.kernel.org]

Han-Wen Nienhuys wrote:

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

_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
Warsaw, Poland
ShadeHawk on #git

Re: describe fails on tagless branch

[Han-Wen Nienhuys]

Jakub Narebski escreveu:
> 
> _Which_ INIT? In git there can be more than one root commit. In git.git

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 - http://www.xs4all.nl/~hanwen

Re: describe fails on tagless branch

[Junio C Hamano]

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

> Jakub Narebski escreveu:
>> 
>> _Which_ INIT? In git there can be more than one root commit. In git.git
>
> 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.

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

Re: describe fails on tagless branch

[Jakub Narebski]

[Cc: git@vger.kernel.org]

Junio C Hamano wrote:

> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> Jakub Narebski escreveu:
>>> 
>>> _Which_ INIT? In git there can be more than one root commit. In git.git
>>
>> 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.
> 
> 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 ||.

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
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: describe fails on tagless branch

[Andy Parkins]

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.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: describe fails on tagless branch

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

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

Re: describe fails on tagless branch

[Andy Parkins]

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

Re: describe fails on tagless branch

[Jakub Narebski]

Andy Parkins wrote:

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

Re: describe fails on tagless branch

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Andy Parkins wrote:
>
>>> 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.

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.