# describe fails on tagless branch 10 messages from 2007-02-07 to 2007-02-07. Participants: Han-Wen Nienhuys, Jakub Narebski, Junio C Hamano, Andy Parkins. Thread: https://gitlist.dev/t/6714 ## Han-Wen Nienhuys, 2007-02-07 00:23 Subject: describe fails on tagless branch Message-ID: URL: https://gitlist.dev/e/eqb660%24ft7%241%40sea.gmane.org ``` 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 ``` ## Jakub Narebski, 2007-02-07 00:40 Subject: Re: describe fails on tagless branch Message-ID: URL: https://gitlist.dev/e/eqb73j%24hri%241%40sea.gmane.org In-Reply-To: ``` [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 ``` ## Han-Wen Nienhuys, 2007-02-07 01:19 Subject: Re: describe fails on tagless branch Message-ID: <45C92918.8010801@xs4all.nl> URL: https://gitlist.dev/e/45C92918.8010801%40xs4all.nl In-Reply-To: ``` 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 already makes the commit uniquely identifiable. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen ``` ## Junio C Hamano, 2007-02-07 02:14 Subject: Re: describe fails on tagless branch Message-ID: <7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr6t2g1dt.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <45C92918.8010801@xs4all.nl> ``` Han-Wen Nienhuys 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 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 ||. ``` ## Jakub Narebski, 2007-02-07 09:08 Subject: Re: describe fails on tagless branch Message-ID: URL: https://gitlist.dev/e/eqc4s4%24nm9%241%40sea.gmane.org In-Reply-To: <7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net> ``` [Cc: git@vger.kernel.org] Junio C Hamano wrote: > Han-Wen Nienhuys 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 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 ``` ## Andy Parkins, 2007-02-07 09:22 Subject: Re: describe fails on tagless branch Message-ID: <200702070922.57163.andyparkins@gmail.com> URL: https://gitlist.dev/e/200702070922.57163.andyparkins%40gmail.com In-Reply-To: <7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Junio C Hamano, 2007-02-07 09:58 Subject: Re: describe fails on tagless branch Message-ID: <7vy7na8f2t.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7na8f2t.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200702070922.57163.andyparkins@gmail.com> ``` Andy Parkins 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. ``` ## Andy Parkins, 2007-02-07 12:01 Subject: Re: describe fails on tagless branch Message-ID: <200702071201.16931.andyparkins@gmail.com> URL: https://gitlist.dev/e/200702071201.16931.andyparkins%40gmail.com In-Reply-To: <7vy7na8f2t.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Jakub Narebski, 2007-02-07 12:37 Subject: Re: describe fails on tagless branch Message-ID: URL: https://gitlist.dev/e/eqch3d%245gc%241%40sea.gmane.org In-Reply-To: <200702071201.16931.andyparkins@gmail.com> ``` 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 ``` ## Junio C Hamano, 2007-02-07 16:29 Subject: Re: describe fails on tagless branch Message-ID: <7vbqk67wz1.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqk67wz1.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Jakub Narebski 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. ```