{"thread":{"id":"25692","subject":"git describe weird behaviour","startedAt":"2010-11-10T01:00:16Z","lastAt":"2010-12-09T03:28:02Z","messageCount":11,"participants":["Miklos Vajna","Jeff King","Maaartin","Thomas Rast","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155557","messageId":"20101110010016.GC22105@genesis.frugalware.org","threadId":"25692","inReplyTo":null,"subject":"git describe weird behaviour","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-11-10T01:00:16Z","receivedAt":"2010-11-10T01:00:16Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Hi,\n\nI'm not sure if this is a bug, so I'm asking.\n\nThe frugalware project (git repo:\nhttp://frugalware.org/git/pub/frugalware/frugalware-current ) has the\ntwo latest tags 1.3 and 1.4pre1, somehow git describe HEAD now mentions\n1.3 and not 1.4pre1 in the output.\n\nTo be more exact:\n\n$ git rev-parse --short HEAD\nf25435f\n\n$ git rev-list 1.4pre1..|wc -l\n871\n\nSo I would exepct 1.4pre1-871-gf25435f. In fact, the output is:\n\n$ git describe\n1.3-3028-gf25435f\n\nOr in case I force the usage of the latest tag:\n\n$ git describe --candidate 1\n1.4pre1-64725-gf25435f\n\nDoes anyone have an idea what's going wrong here?\n\nThanks.\n"},{"id":"155569","messageId":"20101110041428.GA8955@sigill.intra.peff.net","threadId":"25692","inReplyTo":"20101110010016.GC22105@genesis.frugalware.org","subject":"Re: git describe weird behaviour","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-10T04:14:28Z","receivedAt":"2010-11-10T04:14:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[cc'ing Shawn, who probably doesn't remember at all how git-describe\n works these days, but it's worth a shot]\n\nOn Wed, Nov 10, 2010 at 02:00:16AM +0100, Miklos Vajna wrote:\n\n> The frugalware project (git repo:\n> http://frugalware.org/git/pub/frugalware/frugalware-current ) has the\n> two latest tags 1.3 and 1.4pre1, somehow git describe HEAD now mentions\n> 1.3 and not 1.4pre1 in the output.\n> \n> To be more exact:\n> \n> $ git rev-parse --short HEAD\n> f25435f\n> \n> $ git rev-list 1.4pre1..|wc -l\n> 871\n> \n> So I would exepct 1.4pre1-871-gf25435f. In fact, the output is:\n> \n> $ git describe\n> 1.3-3028-gf25435f\n> \n> Or in case I force the usage of the latest tag:\n> \n> $ git describe --candidate 1\n> 1.4pre1-64725-gf25435f\n> \n> Does anyone have an idea what's going wrong here?\n\nThe describe code is pretty inscrutable. But what it should be doing is\nroughly:\n\n  1. Describe all interesting refs (annotated tags by default) by\n     marking the commit object's util field.\n\n  2. Walk backwards in the commit tree. As we walk backwards, keep track\n     of how far (in commits) we have gone. When we see a tag, mark it\n     with how far we've gone.\n\nThe trick is in keeping track of how far we've gone. It looks like we\nkeep the number of seen_commits, increment each time we traverse a\ncommit, and then assign that to the \"depth\" field. But I don't see how\nthat can be right. We are traversing in a breadth-first manner, so we\nmay look at 1000 commits down one ancestry chain of a merge before\nfollowing the first parent on another. But when we finally follow the\nsecond parent, our seen_commits is much higher than the actual distance\nwe had to travel to get here. Looking at the frugalware history in gitk,\nyou might be triggering this; you have a history with just a few merges,\nbut extremely long chains of commits on each branch. Repos like linux or\ngit.git are a bit bushier in the shape of the graph.\n\nBut there's more going on there that I don't quite understand. There is\nsome kind of magic \"within\" flag being kept for each tag we find. It's a\nlittle too late at night for me to wrap my head around it tonight. But I\ndon't think it changes the fundamental issue that our depth value is\njust an estimate; its accuracy works under the assumption that all sides\nof a branch are about equal.\n\nIt seems to me the \"right\" way to do it would be to track the depth to\nget to each commit. We can do this efficiently by just keeping a depth\nmarker for each commit we push onto the commit_list queue. When we visit\neach commit, we know its depth, and when we push on its parents, they\nget its depth+1.\n\nThe patch below implements that in a very rough-and-dirty way. It does\nfind the 1.4 tag in your repository that you expect. However:\n\n  1. This still isn't quite accurate. We might visit a commit by two\n     different paths. When we reach it by a shorter path, we need some\n     way of saying \"oops, the depth on any tags we found following this\n     path are going to be too long. We need to go back and shorten\n     them\".\n\n  2. I am getting nonsensical results when trying it in git.git. It\n     really wants to point me to gitgui tags, which makes no sense. So\n     clearly there is a bug, or my idea is flawed somehow. But it's too\n     late to think about anymore tonight. :)\n\n-Peff\n\nPS This would be a much simpler algorithm to write in a depth-first way.\n   But that would also involve traversing the entire graph down to the\n   roots, which we try to avoid.  Which reminds me of my \"tag\n   --contains\" depth first algorithm, and gives me some ideas on how to\n   make it work in a breadth-first way. So even if my idea here is\n   flawed, this thinking hasn't been completely fruitless. :)\n\n-- >8 --\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex 43caff2..31cf855 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -164,39 +164,6 @@ static int compare_pt(const void *a_, const void *b_)\n \treturn 0;\n }\n \n-static unsigned long finish_depth_computation(\n-\tstruct commit_list **list,\n-\tstruct possible_tag *best)\n-{\n-\tunsigned long seen_commits = 0;\n-\twhile (*list) {\n-\t\tstruct commit *c = pop_commit(list);\n-\t\tstruct commit_list *parents = c->parents;\n-\t\tseen_commits++;\n-\t\tif (c->object.flags & best->flag_within) {\n-\t\t\tstruct commit_list *a = *list;\n-\t\t\twhile (a) {\n-\t\t\t\tstruct commit *i = a->item;\n-\t\t\t\tif (!(i->object.flags & best->flag_within))\n-\t\t\t\t\tbreak;\n-\t\t\t\ta = a->next;\n-\t\t\t}\n-\t\t\tif (!a)\n-\t\t\t\tbreak;\n-\t\t} else\n-\t\t\tbest->depth++;\n-\t\twhile (parents) {\n-\t\t\tstruct commit *p = parents->item;\n-\t\t\tparse_commit(p);\n-\t\t\tif (!(p->object.flags & SEEN))\n-\t\t\t\tinsert_by_date(p, list);\n-\t\t\tp->object.flags |= c->object.flags;\n-\t\t\tparents = parents->next;\n-\t\t}\n-\t}\n-\treturn seen_commits;\n-}\n-\n static void display_name(struct commit_name *n)\n {\n \tif (n->prio == 2 && !n->tag) {\n@@ -231,7 +198,6 @@ static void describe(const char *arg, int last_one)\n \tstruct commit_name *n;\n \tstruct possible_tag all_matches[MAX_TAGS];\n \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n-\tunsigned long seen_commits = 0;\n \tunsigned int unannotated_cnt = 0;\n \n \tif (get_sha1(arg, sha1))\n@@ -262,10 +228,11 @@ static void describe(const char *arg, int last_one)\n \tlist = NULL;\n \tcmit->object.flags = SEEN;\n \tcommit_list_insert(cmit, &list);\n+\tlist->depth = 0;\n \twhile (list) {\n+\t\tunsigned long depth = list->depth;\n \t\tstruct commit *c = pop_commit(&list);\n \t\tstruct commit_list *parents = c->parents;\n-\t\tseen_commits++;\n \t\tn = c->util;\n \t\tif (n) {\n \t\t\tif (!tags && !all && n->prio < 2) {\n@@ -273,7 +240,7 @@ static void describe(const char *arg, int last_one)\n \t\t\t} else if (match_cnt < max_candidates) {\n \t\t\t\tstruct possible_tag *t = &all_matches[match_cnt++];\n \t\t\t\tt->name = n;\n-\t\t\t\tt->depth = seen_commits - 1;\n+\t\t\t\tt->depth = depth;\n \t\t\t\tt->flag_within = 1u << match_cnt;\n \t\t\t\tt->found_order = match_cnt;\n \t\t\t\tc->object.flags |= t->flag_within;\n@@ -285,11 +252,6 @@ static void describe(const char *arg, int last_one)\n \t\t\t\tbreak;\n \t\t\t}\n \t\t}\n-\t\tfor (cur_match = 0; cur_match < match_cnt; cur_match++) {\n-\t\t\tstruct possible_tag *t = &all_matches[cur_match];\n-\t\t\tif (!(c->object.flags & t->flag_within))\n-\t\t\t\tt->depth++;\n-\t\t}\n \t\tif (annotated_cnt && !list) {\n \t\t\tif (debug)\n \t\t\t\tfprintf(stderr, \"finished search at %s\\n\",\n@@ -299,8 +261,10 @@ static void describe(const char *arg, int last_one)\n \t\twhile (parents) {\n \t\t\tstruct commit *p = parents->item;\n \t\t\tparse_commit(p);\n-\t\t\tif (!(p->object.flags & SEEN))\n-\t\t\t\tinsert_by_date(p, &list);\n+\t\t\tif (!(p->object.flags & SEEN)) {\n+\t\t\t\tstruct commit_list *cl = insert_by_date(p, &list);\n+\t\t\t\tcl->depth = depth + 1;\n+\t\t\t}\n \t\t\tp->object.flags |= c->object.flags;\n \t\t\tparents = parents->next;\n \t\t}\n@@ -329,9 +293,7 @@ static void describe(const char *arg, int last_one)\n \n \tif (gave_up_on) {\n \t\tinsert_by_date(gave_up_on, &list);\n-\t\tseen_commits--;\n \t}\n-\tseen_commits += finish_depth_computation(&list, &all_matches[0]);\n \tfree_commit_list(list);\n \n \tif (debug) {\n@@ -341,7 +303,6 @@ static void describe(const char *arg, int last_one)\n \t\t\t\tprio_names[t->name->prio],\n \t\t\t\tt->depth, t->name->path);\n \t\t}\n-\t\tfprintf(stderr, \"traversed %lu commits\\n\", seen_commits);\n \t\tif (gave_up_on) {\n \t\t\tfprintf(stderr,\n \t\t\t\t\"more than %i tags found; listed %i most recent\\n\"\ndiff --git a/commit.h b/commit.h\nindex a3618f8..6493606 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -8,6 +8,7 @@\n \n struct commit_list {\n \tstruct commit *item;\n+\tunsigned long depth;\n \tstruct commit_list *next;\n };\n \n"},{"id":"155579","messageId":"loom.20101110T092918-964@post.gmane.org","threadId":"25692","inReplyTo":"20101110041428.GA8955@sigill.intra.peff.net","subject":"Re: git describe weird behaviour","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-11-10T08:47:55Z","receivedAt":"2010-11-10T08:47:55Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Jeff King <peff <at> peff.net> writes:\n> PS This would be a much simpler algorithm to write in a depth-first way.\n>    But that would also involve traversing the entire graph down to the\n>    roots, which we try to avoid.  Which reminds me of my \"tag\n>    --contains\" depth first algorithm, and gives me some ideas on how to\n>    make it work in a breadth-first way. So even if my idea here is\n>    flawed, this thinking hasn't been completely fruitless. :)\n\nIMHO, using BFS and counting commits is flawed, since the output is hard to \nunderstand and quite meaningless for humans. Imagine a merge of two long \nbranches, one with a tag 10 commits deep and the other with a tag 11 commits \ndeep. Do you see any reason for a human to prefer the first one? I do not.\n\nI could imagine to always prefer the first branch, which leads to DFS. What is \nyour reason for avoiding traversing to the roots?\n\nIt could be better to traverse the first branch only to the point where the \nother started, then traverse the other one, and then continue down the common \ntrunk. This sounds a bit complicated to implement and may be hard to specify in \nmore complicated cases. A rule like \"tag T1 can be returned only if there's no \ntag T2 higher (i.e. newer) in the tree\", could possibly solve it.\n\nFinally, using a chronological ordering instead of counting commits seems to be \nthe most straightforward to me. An implementation using a priority queue is no \nless and no more complicated then BFS or DFS. I think, it could be an \ninteresting and easy to comprehend option. In case I'm talking non-sense, pls \nbare with me, since I'm still a beginner.\n"},{"id":"155580","messageId":"201011100952.34352.trast@student.ethz.ch","threadId":"25692","inReplyTo":"20101110041428.GA8955@sigill.intra.peff.net","subject":"Re: git describe weird behaviour","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-11-10T08:52:34Z","receivedAt":"2010-11-10T08:52:34Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> The trick is in keeping track of how far we've gone. It looks like we\n> keep the number of seen_commits, increment each time we traverse a\n> commit, and then assign that to the \"depth\" field. But I don't see how\n> that can be right. We are traversing in a breadth-first manner, so we\n> may look at 1000 commits down one ancestry chain of a merge before\n> following the first parent on another.\n\nI haven't really spent more than about 3 minutes on this, but it seems\nto use insert_by_date() (except for the start of the search) to walk,\nso it would seem to be affected by date skew in some strange way that\nI have yet to investigate.\n\nSo I merged your git-skew from pu and compiled, and ran\n\n  frugalware-current(master u=)$ git skew --all\n  182448414\n  frugalware-current(master u=)$ python\n  [...]\n  >>> 182448414/86400/365.25\n  5.7796030116358654\n\nUnless I'm reading your commit message a2ffa6b96 wrong, that means the\nrepo has a worst-case clock skew of on the order of *six years*...  So\nmaybe it's once again an undocumented effect of clock skew on our\nhistory walks?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"155591","messageId":"20101110140334.GJ22105@genesis.frugalware.org","threadId":"25692","inReplyTo":"20101110041428.GA8955@sigill.intra.peff.net","subject":"Re: git describe weird behaviour","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-11-10T14:03:34Z","receivedAt":"2010-11-10T14:03:34Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Nov 09, 2010 at 11:14:28PM -0500, Jeff King <peff@peff.net> wrote:\n> we had to travel to get here. Looking at the frugalware history in gitk,\n> you might be triggering this; you have a history with just a few merges,\n> but extremely long chains of commits on each branch. Repos like linux or\n> git.git are a bit bushier in the shape of the graph.\n\nAgreed.\n\nActually I thought git describe is just a C version of something like:\n\n- run git log, find the first reachable tag (1.4pre1 in this case)\n- git rev-list 1.4pre1..|wc -l (880 in this case)\n- append \"-g<hash>\" to make it still unique\n\nThen it turned out it's a bit more complicated, so I mailed the list. :)\n\n> The patch below implements that in a very rough-and-dirty way. It does\n> find the 1.4 tag in your repository that you expect. However:\n\nYes, works here as well:\n\n$ ~/git/git/git describe\n1.4pre1-210-g48b67cd\n\n>   2. I am getting nonsensical results when trying it in git.git. It\n>      really wants to point me to gitgui tags, which makes no sense. So\n>      clearly there is a bug, or my idea is flawed somehow. But it's too\n>      late to think about anymore tonight. :)\n> \n> -Peff\n> \n> PS This would be a much simpler algorithm to write in a depth-first way.\n>    But that would also involve traversing the entire graph down to the\n>    roots, which we try to avoid.  Which reminds me of my \"tag\n>    --contains\" depth first algorithm, and gives me some ideas on how to\n>    make it work in a breadth-first way. So even if my idea here is\n>    flawed, this thinking hasn't been completely fruitless. :)\n\nHm, but can't we way git describe does history walk in a --first-parent\nway? It might not be efficient, but what may work is to:\n\n- traverse the history by using the first parrents only to find the\n  first reachable tag (this way you will never hit git-gui tags)\n- count the commits from the first tag till HEAD by traversing the other\n  parents as well\n\nTo sum up, I think your patch is great about it picks up the right tag\nfor me, though:\n\n$ git rev-list 1.4pre1..|wc -l\n880 <- this is what I would expect in the git describe output\n$ git rev-list --first-parent 1.4pre1..|wc -l\n569 <- this is less informative, though probably is faster to produce\n(we may have this info already when searching for the first tag)\n$ ~/git/git/git describe\n1.4pre1-210-g48b67cd <- an even smaller number you give. :)\n\nThanks!\n"},{"id":"155614","messageId":"7vaalhhstp.fsf@alter.siamese.dyndns.org","threadId":"25692","inReplyTo":"20101110010016.GC22105@genesis.frugalware.org","subject":"Re: git describe weird behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-10T19:38:58Z","receivedAt":"2010-11-10T19:38:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Just a guess.  Does this have to do with 80dbae0 (Chose better tag names\nin git-describe after merges., 2007-01-10)?\n"},{"id":"155624","messageId":"20101110204034.GO22105@genesis.frugalware.org","threadId":"25692","inReplyTo":"7vaalhhstp.fsf@alter.siamese.dyndns.org","subject":"Re: git describe weird behaviour","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-11-10T20:40:34Z","receivedAt":"2010-11-10T20:40:34Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Nov 10, 2010 at 11:38:58AM -0800, Junio C Hamano <gitster@pobox.com> wrote:\n> Just a guess.  Does this have to do with 80dbae0 (Chose better tag names\n> in git-describe after merges., 2007-01-10)?\n\nHmm, not sure. I tried reverting that commit, but that resulted in\nconflicts - git checkout 80dbae0^ produces a git binary that can't read\nthe index version we have today. :)\n\nBut I think the approach to follow the first parent only would solve the\nproblem outlined in the commit message of 80dbae0 as well: I think it's\npretty rare to tag a commit in a feature branch, then merge it.\n\nI mean the trivial proof of concenpt below finds the right tag here:\n\n$ ~/git/git/git describe\n1.4pre1-572-g42b497b\n\nEven if it does not count all the commits since that tag:\n\n$ git rev-list 1.4pre1..|wc -l\n883\n\nThanks.\n\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex 43caff2..f32eaf4 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -303,6 +303,7 @@ static void describe(const char *arg, int last_one)\n \t\t\t\tinsert_by_date(p, &list);\n \t\t\tp->object.flags |= c->object.flags;\n \t\t\tparents = parents->next;\n+\t\t\tbreak;\n \t\t}\n \t}\n \n"},{"id":"155626","messageId":"20101110212410.GA13782@burratino","threadId":"25692","inReplyTo":"20101110204034.GO22105@genesis.frugalware.org","subject":"Re: git describe weird behaviour","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-10T21:24:10Z","receivedAt":"2010-11-10T21:24:10Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Miklos Vajna wrote:\n\n> But I think the approach to follow the first parent only would solve the\n> problem outlined in the commit message of 80dbae0 as well: I think it's\n> pretty rare to tag a commit in a feature branch, then merge it.\n\nDoesn't that happen in linux-2.6 history fairly often (subsystem trees\nsyncing with upstream)?\n"},{"id":"155628","messageId":"20101110220730.GR22105@genesis.frugalware.org","threadId":"25692","inReplyTo":"20101110212410.GA13782@burratino","subject":"Re: git describe weird behaviour","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-11-10T22:07:30Z","receivedAt":"2010-11-10T22:07:30Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Nov 10, 2010 at 03:24:10PM -0600, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Miklos Vajna wrote:\n> \n> > But I think the approach to follow the first parent only would solve the\n> > problem outlined in the commit message of 80dbae0 as well: I think it's\n> > pretty rare to tag a commit in a feature branch, then merge it.\n> \n> Doesn't that happen in linux-2.6 history fairly often (subsystem trees\n> syncing with upstream)?\n\nHm, makes sense - I don't think it ever happened in\ntorvalds/linux-2.6.git, but probably it happens in subsystem trees where\na given maintainer never tags anything, but regularly merges from\ntorvalds/linux-2.6.git. So my proposal would break git describe output\nwhen it's invoked in a subsystem tree, you are right.\n\n(Note that Peff's patch at least fixes the tag part of the issue for me,\nand that should not really break the above situation.)\n"},{"id":"157658","messageId":"20101209013323.GJ22105@genesis.frugalware.org","threadId":"25692","inReplyTo":"20101110140334.GJ22105@genesis.frugalware.org","subject":"Re: git describe weird behaviour","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-12-09T01:33:23Z","receivedAt":"2010-12-09T01:33:23Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Nov 10, 2010 at 03:03:34PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:\n> > The patch below implements that in a very rough-and-dirty way. It does\n> > find the 1.4 tag in your repository that you expect. However:\n> \n> Yes, works here as well:\n> \n> $ ~/git/git/git describe\n> 1.4pre1-210-g48b67cd\n\nAny update on this? I still have this patch in my tree to get correct\ngit describe output. :)\n\nThanks.\n"},{"id":"157666","messageId":"20101209032802.GA18773@sigill.intra.peff.net","threadId":"25692","inReplyTo":"20101209013323.GJ22105@genesis.frugalware.org","subject":"Re: git describe weird behaviour","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-12-09T03:28:02Z","receivedAt":"2010-12-09T03:28:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 09, 2010 at 02:33:23AM +0100, Miklos Vajna wrote:\n\n> On Wed, Nov 10, 2010 at 03:03:34PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:\n> > > The patch below implements that in a very rough-and-dirty way. It does\n> > > find the 1.4 tag in your repository that you expect. However:\n> > \n> > Yes, works here as well:\n> > \n> > $ ~/git/git/git describe\n> > 1.4pre1-210-g48b67cd\n> \n> Any update on this? I still have this patch in my tree to get correct\n> git describe output. :)\n\nSorry, no, I haven't had time to think about it, and I probably won't\nfor a few more weeks at least.\n\nThe patch I posted was giving some really weird results for git.git,\nthough, so it is definitely not OK for inclusion as-is.\n\n-Peff\n"}]}