{"thread":{"id":"6714","subject":"describe fails on tagless branch","startedAt":"2007-02-07T00:23:38Z","lastAt":"2007-02-07T16:29:06Z","messageCount":10,"participants":["Han-Wen Nienhuys","Jakub Narebski","Junio C Hamano","Andy Parkins"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33761","messageId":"eqb660$ft7$1@sea.gmane.org","threadId":"6714","inReplyTo":null,"subject":"describe fails on tagless branch","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-02-07T00:23:38Z","receivedAt":"2007-02-07T00:23:38Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"\n\ntry \n\n  git init\n  echo hoi > a\n  git add a\n  git commit -m 'add a' a\n  git describe\n\nthis yields\n\n\n[lilydev@haring t]$ git describe\nfatal: cannot describe '3b26396bbb5f18580ffd4bc31f70ef0738ec73d6'\n\n\nI would prefer it if an implicit tag INIT was supposed at the start of the\nhistory, so we'd get\n\n  INIT-3b2...\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"33762","messageId":"eqb73j$hri$1@sea.gmane.org","threadId":"6714","inReplyTo":"eqb660$ft7$1@sea.gmane.org","subject":"Re: describe fails on tagless branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T00:40:51Z","receivedAt":"2007-02-07T00:40:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nHan-Wen Nienhuys wrote:\n\n> try \n> \n>   git init\n>   echo hoi > a\n>   git add a\n>   git commit -m 'add a' a\n>   git describe\n> \n> this yields\n> \n> \n> [lilydev@haring t]$ git describe\n> fatal: cannot describe '3b26396bbb5f18580ffd4bc31f70ef0738ec73d6'\n> \n> \n> I would prefer it if an implicit tag INIT was supposed at the start of the\n> history, so we'd get\n> \n>   INIT-3b2...\n\n_Which_ INIT? In git there can be more than one root commit. In git.git\nrepository mainline (maint, master, next and pu branches) has 4 roots\n(plus three linear independent branches: man, html and todo, each with its\nown root).\n\nI agree that error description should probably be better: cannot describe\n_why_.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33764","messageId":"45C92918.8010801@xs4all.nl","threadId":"6714","inReplyTo":"eqb73j$hri$1@sea.gmane.org","subject":"Re: describe fails on tagless branch","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-02-07T01:19:20Z","receivedAt":"2007-02-07T01:19:20Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Jakub Narebski escreveu:\n> \n> _Which_ INIT? In git there can be more than one root commit. In git.git\n\nI don't really care, but I would like git-describe to produce something \nuseful in the absence of tags.  The -g<SHA-1> already makes the commit\nuniquely identifiable.\n\n\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"33765","messageId":"7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net","threadId":"6714","inReplyTo":"45C92918.8010801@xs4all.nl","subject":"Re: describe fails on tagless branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T02:14:22Z","receivedAt":"2007-02-07T02:14:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys <hanwen@xs4all.nl> writes:\n\n> Jakub Narebski escreveu:\n>> \n>> _Which_ INIT? In git there can be more than one root commit. In git.git\n>\n> I don't really care, but I would like git-describe to produce something \n> useful in the absence of tags.  The -g<SHA-1> already makes the commit\n> uniquely identifiable.\n\nThen you would script like this:\n\n\t#!/bin/sh\n\tgit describe \"$1\" 2>/dev/null || git rev-parse --verify \"$1\"\n\nI do not think it a good idea to make \"git-describe\" itself do\nthe above, as the user of describe may want to fall back on\nsomething other than \"rev-parse --verify\" after ||.\n"},{"id":"33777","messageId":"eqc4s4$nm9$1@sea.gmane.org","threadId":"6714","inReplyTo":"7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net","subject":"Re: describe fails on tagless branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T09:08:50Z","receivedAt":"2007-02-07T09:08:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nJunio C Hamano wrote:\n\n> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:\n> \n>> Jakub Narebski escreveu:\n>>> \n>>> _Which_ INIT? In git there can be more than one root commit. In git.git\n>>\n>> I don't really care, but I would like git-describe to produce something \n>> useful in the absence of tags.  The -g<SHA-1> already makes the commit\n>> uniquely identifiable.\n> \n> Then you would script like this:\n> \n>       #!/bin/sh\n>       git describe \"$1\" 2>/dev/null || git rev-parse --verify \"$1\"\n> \n> I do not think it a good idea to make \"git-describe\" itself do\n> the above, as the user of describe may want to fall back on\n> something other than \"rev-parse --verify\" after ||.\n\nBy the way, new git-describe gives us also number of commits since\ntag, and it would be nice to have number of commits since init...\nbut that can be easily obtained using \"git rev-list $1 | wc -l\".\n\nI guess that some use git-describe with --abbrev=0 to get closest\npreceding tag: getting INIT would confuse them.\n\nThat said, we could use e.g. INITg2a45ba+10-g4ee2ab\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33780","messageId":"200702070922.57163.andyparkins@gmail.com","threadId":"6714","inReplyTo":"7vr6t2g1dt.fsf@assigned-by-dhcp.cox.net","subject":"Re: describe fails on tagless branch","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-07T09:22:54Z","receivedAt":"2007-02-07T09:22:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 07 02:14, Junio C Hamano wrote:\n\n> I do not think it a good idea to make \"git-describe\" itself do\n> the above, as the user of describe may want to fall back on\n> something other than \"rev-parse --verify\" after ||.\n\nAgreed - the \"nearest tag\" mode (--abbrev=0) would be broken in that it \ngit-describe would return a tag that doesn't exist.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33785","messageId":"7vy7na8f2t.fsf@assigned-by-dhcp.cox.net","threadId":"6714","inReplyTo":"200702070922.57163.andyparkins@gmail.com","subject":"Re: describe fails on tagless branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T09:58:02Z","receivedAt":"2007-02-07T09:58:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Wednesday 2007 February 07 02:14, Junio C Hamano wrote:\n>\n>> I do not think it a good idea to make \"git-describe\" itself do\n>> the above, as the user of describe may want to fall back on\n>> something other than \"rev-parse --verify\" after ||.\n>\n> Agreed - the \"nearest tag\" mode (--abbrev=0) would be broken in that it \n> git-describe would return a tag that doesn't exist.\n\n\"describe\" is about giving a short name for public communication\nto a commit in terms of well known tags.  If there is no tag,\nthen it is natural to say that the commit is indescribable.\n\nIn the case of \"git-describe --abbrev=0 $indescribable\", it\ncould return an empty string, since there is no nearest tag\nafter all.  But that would not apply to non --abbrev=0 case.\n\nReally, people should not be afraid to script a few-liner.  Who\ncares if \"git describe HEAD\" says \"can't\" in an interactive\nsession?  And if you are scripting, and if you want your script\nto say something usable even for indescribable commits, then you\nwould want to have an easy way to tell if the commit is\ndescribable or not.  Changing it not to fail like it currently\ndoes means the script needs to do something more than just check\nthe return value from describe $? in order to fall back on\nwhatever alternative behaviour it wants to implement.\n\nIt might not be a bad idea to give '-q' option to make it silent\nwhen it fails because the commit is indescribable.\n"},{"id":"33797","messageId":"200702071201.16931.andyparkins@gmail.com","threadId":"6714","inReplyTo":"7vy7na8f2t.fsf@assigned-by-dhcp.cox.net","subject":"Re: describe fails on tagless branch","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-07T12:01:16Z","receivedAt":"2007-02-07T12:01:16Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 07 09:58, Junio C Hamano wrote:\n\n> > Agreed - the \"nearest tag\" mode (--abbrev=0) would be broken in that it\n> > git-describe would return a tag that doesn't exist.\n>\n> \"describe\" is about giving a short name for public communication\n> to a commit in terms of well known tags.  If there is no tag,\n> then it is natural to say that the commit is indescribable.\n>\n> In the case of \"git-describe --abbrev=0 $indescribable\", it\n> could return an empty string, since there is no nearest tag\n> after all.  But that would not apply to non --abbrev=0 case.\n\nAbsolutely.  I agree entirely.  The /only/ valid thing to return when \ngit-describe is asked \"what is the nearest tag\" when there is no tag is \nnothing.  I don't see how it could be otherwise.  If there were a way to \nreturn NULL instead of \"\" then I'd vote for that (actually we could argue \nthat the return code tells you it's NULL); however that's moot since it's not \npossible to have empty tags.\n\ngit-describe returns an empty string whatever the --abbrev when there is no \ntag.  To my mind it's working perfectly.  Every case is both handled and \ndetectable.  What more could it do?\n\nSlight aside: The only thing that has ever crossed my mind as an improvement \nto git-describe would be to get at its revision counting mechanism.  Just for \nfun really as I don't think it's that useful in the real world.  Wouldn't it \nbe interesting if you could say:\n\n $ git-describe --revisions-per-tag HEAD\n 30% v1.0.0\n 20% v1.1.0\n 15% v1.2.0\n 13% v1.3.0\n 12% v1.4.0\n 4%  v1.5.0\n 1%  (indescribable)\n \nHowever, I think I'm just being silly :-)\n\n> It might not be a bad idea to give '-q' option to make it silent\n> when it fails because the commit is indescribable.\n\nI don't think it's worth it.  The \"-q\" be used only in scripts, and in a \nscript you would do the whole \"2> /dev/null || echo 'No tag found'\" thing \nanyway.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33800","messageId":"eqch3d$5gc$1@sea.gmane.org","threadId":"6714","inReplyTo":"200702071201.16931.andyparkins@gmail.com","subject":"Re: describe fails on tagless branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T12:37:32Z","receivedAt":"2007-02-07T12:37:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n>> It might not be a bad idea to give '-q' option to make it silent\n>> when it fails because the commit is indescribable.\n> \n> I don't think it's worth it.  The \"-q\" be used only in scripts, and in a \n> script you would do the whole \"2> /dev/null || echo 'No tag found'\" thing \n> anyway.\n\nIt would be worth for Perl (for gitweb) to be able to use list form of magic\nopen, without spawning shell (and assorted argument quoting troubles), but\nsilently. \n\nI think it would be fairly easy to add -q option to git wrapper: it would\nsimply set die, error and warn routines and no-op (no-write) versions.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33818","messageId":"7vbqk67wz1.fsf@assigned-by-dhcp.cox.net","threadId":"6714","inReplyTo":"eqch3d$5gc$1@sea.gmane.org","subject":"Re: describe fails on tagless branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-07T16:29:06Z","receivedAt":"2007-02-07T16:29:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Andy Parkins wrote:\n>\n>>> It might not be a bad idea to give '-q' option to make it silent\n>>> when it fails because the commit is indescribable.\n>> \n>> I don't think it's worth it.  The \"-q\" be used only in scripts, and in a \n>> script you would do the whole \"2> /dev/null || echo 'No tag found'\" thing \n>> anyway.\n>\n> It would be worth for Perl (for gitweb) to be able to use list form of magic\n> open, without spawning shell (and assorted argument quoting troubles), but\n> silently. \n>\n> I think it would be fairly easy to add -q option to git wrapper: it would\n> simply set die, error and warn routines and no-op (no-write) versions.\n\nYou completely missed my point.  describe -q would not squelch\n*all* errors and die()'s, but only the specific \"this cannot be\ndescribed\".  If you give a non-existent object name on the\ncommand line, it _should_ barf loudly.\n"}]}