{"thread":{"id":"6558","subject":"[PATCH 2/4] If abbrev is set to zero in git-describe, don't add the unique suffix","startedAt":"2007-01-27T06:53:51Z","lastAt":"2007-01-28T07:24:49Z","messageCount":6,"participants":["Shawn O. Pearce","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"32806","messageId":"20070127065351.GB10380@spearce.org","threadId":"6558","inReplyTo":"a23c4e55ca5c09f742fa2a047e45613e7797e720.1169880681.git.spearce@spearce.org","subject":"[PATCH 2/4] If abbrev is set to zero in git-describe, don't add the unique suffix","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-27T06:53:51Z","receivedAt":"2007-01-27T06:53:51Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"From: Andy Parkins \n\nWhen on a non-tag commit, git-describe normally outputs descriptions of\nthe form\n v1.0.0-g1234567890\nSome scripts (for example the update hook script) might just want to\nknow the name of the nearest tag, so they then have to do\n x=$(git-describe HEAD | sed 's/-g*//')\nThis is costly, but more importantly is fragile as it is relying on the\noutput format of git-describe, which we would then have to maintain\nforever.\n\nThis patch adds support for setting the --abbrev option to zero. In\nthat case git-describe does as it always has, but outputs only the\nnearest found tag instead of a completely unique name. This means that\nscripts would not have to parse the output format and won't need\nchanging if the git-describe suffix is ever changed.\n\nSigned-off-by: Andy Parkins \nSigned-off-by: Shawn O. Pearce \n---\n\n This is a resend of Andy's original patch. I added documentation\n updates and slighlty modified the code so it conformed to our\n conventions. Reason is, my next patch alters the same lines...\n\n Documentation/git-describe.txt | 7 ++++++-\n builtin-describe.c | 9 ++++++---\n 2 files changed, 12 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex b87783c..a615996 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -33,7 +33,9 @@ OPTIONS\n \n --abbrev=::\n \tInstead of using the default 8 hexadecimal digits as the\n-\tabbreviated object name, use digits.\n+\tabbreviated object name, use digits. If set to 0\n+\tthen abbreviated object name will not be displayed on\n+\ta non-exact match.\n \n --candidates=::\n \tInstead of considering only the 10 most recent tags as\n@@ -70,6 +72,9 @@ the output shows the reference path as well:\n \t[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2\n \ttags/v1.0.0-g975b\n \n+\t[torvalds@g5 git]$ git describe --all --abbrev=0 v1.0.5^2\n+\ttags/v1.0.0\n+\n \t[torvalds@g5 git]$ git describe --all HEAD^\n \theads/lt/describe-g975b\n \ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex f8afb9c..70578dc 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -188,8 +188,11 @@ static void describe(const char *arg, int last_one)\n \t\t\t\tsha1_to_hex(gave_up_on->object.sha1));\n \t\t}\n \t}\n-\tprintf(\"%s-g%s\\n\", all_matches[0].name->path,\n-\t\t find_unique_abbrev(cmit->object.sha1, abbrev));\n+\tif (!abbrev)\n+\t\tprintf(\"%s\\n\", all_matches[0].name->path);\n+\telse\n+\t\tprintf(\"%s-g%s\\n\", all_matches[0].name->path,\n+\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n \n \tif (!last_one)\n \t\tclear_commit_marks(cmit, -1);\n@@ -212,7 +215,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\t\ttags = 1;\n \t\telse if (!strncmp(arg, \"--abbrev=\", 9)) {\n \t\t\tabbrev = strtoul(arg + 9, NULL, 10);\n-\t\t\tif (abbrev < MINIMUM_ABBREV || 40 < abbrev)\n+\t\t\tif (abbrev && (abbrev < MINIMUM_ABBREV || 40 < abbrev))\n \t\t\t\tabbrev = DEFAULT_ABBREV;\n \t\t}\n \t\telse if (!strncmp(arg, \"--candidates=\", 13)) {\n-- \n1.5.0.rc2.g8a816\n"},{"id":"32807","messageId":"20070127065413.GC10380@spearce.org","threadId":"6558","inReplyTo":"a23c4e55ca5c09f742fa2a047e45613e7797e720.1169880681.git.spearce@spearce.org","subject":"[PATCH 3/4] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-27T06:54:13Z","receivedAt":"2007-01-27T06:54:13Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano :\n> However, I suspect that we could do better with Shawn's new\n> fangled describe implementation that actually counts the\n> distance between what is described and the tag. We could add\n> \"number of commits since the tag\" somewhere, to describe:\n>\n> v2.6.20-rc5-256-g419dd83\n> v2.6.20-rc5-217-gde14569\n>\n> to say that the first one has 256 commits accumulated since the\n> given tag \"v2.6.20-rc5\" and the second one has only 217\n> commits, to get the sense of how busy the development activity\n> is.\n>\n> Is it useful? That is something I am not sure.\n\nYes, its very useful. If you get two different describes at different\ntimes from a non-rewinding branch and they both come up with the same\ntag name, you can tell which is the 'newer' one by distance. This is\nrather common in practice, so its incredibly useful.\n\nCredit for this idea also goes to Jakub Narebski for suggesting:\n\n v2.6.20-rc5+256-g419dd83\n v2.6.20-rc5+217-gde14569\n\nThe + format is much easier to read and understand than the - format\noriginal proposed by Junio.\n\nSigned-off-by: Shawn O. Pearce \n---\n Documentation/git-describe.txt | 23 ++++++++++++++---------\n builtin-describe.c | 3 ++-\n 2 files changed, 16 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex a615996..b3e9276 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -14,8 +14,8 @@ DESCRIPTION\n -----------\n The command finds the most recent tag that is reachable from a\n commit, and if the commit itself is pointed at by the tag, shows\n-the tag. Otherwise, it suffixes the tag name with abbreviated\n-object name of the commit.\n+the tag. Otherwise, it suffixes the tag name with the number of\n+additional commits and the abbreviated object name of the commit.\n \n \n OPTIONS\n@@ -54,12 +54,17 @@ EXAMPLES\n With something like git.git current tree, I get:\n \n \t[torvalds@g5 git]$ git-describe parent\n-\tv1.0.4-g2414721b\n+\tv1.0.4+14-g2414721\n \n-i.e. the current head of my \"parent\" branch is based on v1.0.4,\n-but since it has a few commits on top of that, it has added the\n-git hash of the thing to the end: \"-g\" + 8-char shorthand for\n-the commit `2414721b194453f058079d897d13c4e377f92dc6`.\n+i.e. the current head of my \"parent\" branch is based on v1.0.4.\n+But since my parent branch has a few commits on top of that,\n+describe has added the number of additional commits (\"+14\") and\n+the hash of the tip commit (\"-g2414721\") to the end.\n+\n+The number of additional commits is an estimate of the number\n+of commits which would be displayed by \"git log v1.0.4..parent\".\n+The hash suffix is \"-g\" + 8-char abbreviation for the tip commit\n+of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).\n \n Doing a \"git-describe\" on a tag-name will just show the tag name:\n \n@@ -70,13 +75,13 @@ With --all, the command can use branch heads as references, so\n the output shows the reference path as well:\n \n \t[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2\n-\ttags/v1.0.0-g975b\n+\ttags/v1.0.0+21-g975b\n \n \t[torvalds@g5 git]$ git describe --all --abbrev=0 v1.0.5^2\n \ttags/v1.0.0\n \n \t[torvalds@g5 git]$ git describe --all HEAD^\n-\theads/lt/describe-g975b\n+\theads/lt/describe+5-g975b\n \n SEARCH STRATEGY\n ---------------\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex 70578dc..6e59e75 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -191,7 +191,8 @@ static void describe(const char *arg, int last_one)\n \tif (!abbrev)\n \t\tprintf(\"%s\\n\", all_matches[0].name->path);\n \telse\n-\t\tprintf(\"%s-g%s\\n\", all_matches[0].name->path,\n+\t\tprintf(\"%s+%d-g%s\\n\", all_matches[0].name->path,\n+\t\t\tall_matches[0].depth,\n \t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n \n \tif (!last_one)\n-- \n1.5.0.rc2.g8a816\n"},{"id":"32808","messageId":"20070127065421.GD10380@spearce.org","threadId":"6558","inReplyTo":"a23c4e55ca5c09f742fa2a047e45613e7797e720.1169880681.git.spearce@spearce.org","subject":"[PATCH 4/4] Compute accurate distances in git-describe before output.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-27T06:54:21Z","receivedAt":"2007-01-27T06:54:21Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"My prior change to git-describe attempts to print the distance\nbetween the input commit and the best matching tag, but this distance\nwas usually only an estimate as we always aborted revision walking\nas soon as we overflowed the configured limit on the number of\npossible tags (as set by --candidates).\n\nDisplaying an estimated distance is not very useful and can just be\ndownright confusing. Most users (heck, most Git developers) don't\nimmediately understand why this distance differs from the output\nof common tools such as `git rev-list | wc -l`. Even worse, the\nestimated distance could change in the future (including decreasing\ndespite no rebase occuring) if we find more possible tags earlier\non during traversal. (This could happen if more tags are merged\ninto the branch between queries.) These factors basically make an\nestimated distance useless.\n\nFortunately we are usually most of the way through an accurate\ndistance computation by the time we abort (due to reaching the\ncurrent --candidates limit). This means we can simply finish\ncounting out the revisions still in our commit queue to present\nthe accurate distance at the end. The number of commits remaining\nin the commit queue is probably less than the number of commits\nalready traversed, so finishing out the count is not likely to take\nvery long. This final distance will then always match the output of\n`git rev-list | wc -l`.\n\nWe can easily reduce the total number of commits that need to be\nwalked at the end by stopping as soon as all of the commits in the\ncommit queue are flagged as being merged into the already selected\nbest possible tag. If that's true then there are no remaining\nunseen commits which can contribute to our best possible tag's\ndepth counter, so further traversal is useless.\n\nBasic testing on my Mac OS X system shows there is no noticable\nperformance difference between this accurate distance counting\nversion of git-describe and the prior version of git-describe,\nat least when run on git.git.\n\nSigned-off-by: Shawn O. Pearce \n---\n Documentation/git-describe.txt | 2 +-\n builtin-describe.c | 42 +++++++++++++++++++++++++++++++++++++++-\n 2 files changed, 42 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex b3e9276..160779a 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -61,7 +61,7 @@ But since my parent branch has a few commits on top of that,\n describe has added the number of additional commits (\"+14\") and\n the hash of the tip commit (\"-g2414721\") to the end.\n \n-The number of additional commits is an estimate of the number\n+The number of additional commits shown after the tag is the number\n of commits which would be displayed by \"git log v1.0.4..parent\".\n The hash suffix is \"-g\" + 8-char abbreviation for the tip commit\n of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex 6e59e75..2ad3c16 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -91,6 +91,39 @@ 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 describe(const char *arg, int last_one)\n {\n \tunsigned char sha1[20];\n@@ -166,12 +199,19 @@ static void describe(const char *arg, int last_one)\n \t\t\tparents = parents->next;\n \t\t}\n \t}\n-\tfree_commit_list(list);\n \n \tif (!match_cnt)\n \t\tdie(\"cannot describe '%s'\", sha1_to_hex(cmit->object.sha1));\n \n \tqsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);\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 \t\tfor (cur_match = 0; cur_match < match_cnt; cur_match++) {\n \t\t\tstruct possible_tag *t = &all_matches[cur_match];\n-- \n1.5.0.rc2.g8a816\n"},{"id":"32816","messageId":"7v4pqcluum.fsf@assigned-by-dhcp.cox.net","threadId":"6558","inReplyTo":"20070127065413.GC10380@spearce.org","subject":"Re: [PATCH 3/4] Teach git-describe to display distances from tags.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-27T08:47:13Z","receivedAt":"2007-01-27T08:47:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Junio C Hamano :\n>> However, I suspect that we could do better with Shawn's new\n>> fangled describe implementation that actually counts the\n>> distance between what is described and the tag. We could add\n>> \"number of commits since the tag\" somewhere, to describe:\n>>\n>> v2.6.20-rc5-256-g419dd83\n>> v2.6.20-rc5-217-gde14569\n> ...\n> v2.6.20-rc5+256-g419dd83\n> v2.6.20-rc5+217-gde14569\n>\n> The + format is much easier to read and understand than the - format\n> original proposed by Junio.\n\nI tend to disagree (I do not claim + is _less_ easier to read,\nthough).\n\nThey are of comparable readability, and I think plus breaks\nGIT-VERSION-GEN (the primary reason it replaces '-' to '.' is\nto work around RPM limitation IIRC, and I do not know what '+'\ndoes to RPM offhand).\n\nBut I do not have a strong feeling either way.\n"},{"id":"32831","messageId":"Pine.LNX.4.63.0701271348330.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6558","inReplyTo":"7v4pqcluum.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/4] Teach git-describe to display distances from tags.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-27T12:50:51Z","receivedAt":"2007-01-27T12:50:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 27 Jan 2007, Junio C Hamano wrote:\n\n> \"Shawn O. Pearce\" writes:\n> \n> > The + format is much easier to read and understand than the - format \n> > original proposed by Junio.\n> \n> I tend to disagree (I do not claim + is _less_ easier to read, though).\n> \n> They are of comparable readability, and I think plus breaks \n> GIT-VERSION-GEN (the primary reason it replaces '-' to '.' is to work \n> around RPM limitation IIRC, and I do not know what '+' does to RPM \n> offhand).\n\nNote that scripts using git-describe to name archives break also on \nchallenged file / operating systems. IIRC on DOS/FAT32 '+' has problems \nwith it.\n\n> But I do not have a strong feeling either way.\n\nNeither have I.\n\nCiao,\nDscho\n"},{"id":"32900","messageId":"20070128072449.GA9781@spearce.org","threadId":"6558","inReplyTo":"Pine.LNX.4.63.0701271348330.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/4] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-28T07:24:49Z","receivedAt":"2007-01-28T07:24:49Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Sat, 27 Jan 2007, Junio C Hamano wrote:\n> > \"Shawn O. Pearce\" writes:\n> > \n> > > The + format is much easier to read and understand than the - format \n> > > original proposed by Junio.\n> > \n> > I tend to disagree (I do not claim + is _less_ easier to read, though).\n> > \n> > They are of comparable readability, and I think plus breaks \n> > GIT-VERSION-GEN (the primary reason it replaces '-' to '.' is to work \n> > around RPM limitation IIRC, and I do not know what '+' does to RPM \n> > offhand).\n> \n> Note that scripts using git-describe to name archives break also on \n> challenged file / operating systems. IIRC on DOS/FAT32 '+' has problems \n> with it.\n> \n> > But I do not have a strong feeling either way.\n> \n> Neither have I.\n\nMe neither, actually. The + just felt more right, as its literally\n\"that tag, plus n commits\".\n\nBut if + is going to cause pain on operating systems that somehow\ndecided disallowing bytes other than NUL was OK and the right thing\nto do, then maybe - is the safer choice here.\n\n-- \nShawn.\n"}]}