{"thread":{"id":"6527","subject":"[PATCH 1/2] Teach git-describe to display distances from tags.","startedAt":"2007-01-25T17:39:54Z","lastAt":"2007-01-26T19:37:36Z","messageCount":15,"participants":["Shawn O. Pearce","Junio C Hamano","Nicolas Pitre","Francis Moreau","Andy Parkins","Jakub Narebski","Matthias Lederhofer"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"32628","messageId":"20070125173954.GA13276@spearce.org","threadId":"6527","inReplyTo":null,"subject":"[PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-25T17:39:54Z","receivedAt":"2007-01-25T17:39:54Z","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\nSigned-off-by: Shawn O. Pearce \n---\n builtin-describe.c | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex e7b8f95..d8ff621 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -189,7 +189,8 @@ 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+\tprintf(\"%s-%i-g%s\\n\", all_matches[0].name->path,\n+\t\t all_matches[0].depth,\n \t\t find_unique_abbrev(cmit->object.sha1, abbrev));\n \n \tif (!last_one)\n-- \n1.5.0.rc2.g18af\n"},{"id":"32639","messageId":"7vmz46ajcq.fsf@assigned-by-dhcp.cox.net","threadId":"6527","inReplyTo":"20070125173954.GA13276@spearce.org","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-25T21:26:29Z","receivedAt":"2007-01-25T21:26:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Yes, its very useful. If you get two different describes at different\n> times from a non-rewinding branch and they both come up with the same\n> tag name, you can tell which is the 'newer' one by distance. This is\n> rather common in practice, so its incredibly useful.\n>\n> Signed-off-by: Shawn O. Pearce \n> ---\n> builtin-describe.c | 3 ++-\n> 1 files changed, 2 insertions(+), 1 deletions(-)\n>\n> diff --git a/builtin-describe.c b/builtin-describe.c\n> index e7b8f95..d8ff621 100644\n> --- a/builtin-describe.c\n> +++ b/builtin-describe.c\n> @@ -189,7 +189,8 @@ 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> +\tprintf(\"%s-%i-g%s\\n\", all_matches[0].name->path,\n> +\t\t all_matches[0].depth,\n> \t\t find_unique_abbrev(cmit->object.sha1, abbrev));\n> \n> \tif (!last_one)\n\nTwo comments.\n\n - This is purely style, but we seem to prefer %d instead of %i\n elsewhere in the code (three existing offenders are\n builtin-describe.c, receive-pack.c and sha1_file which we may\n want to clean up for consistency).\n\n - How much damage are we talking about with this patch to\n People's existing scripts? I expect they all extract the\n hash from last -g (because they cannot rely on particular\n convention in tagnames), but I am also worried if people are\n expecting everything that comes before the last -g is the\n whole tag.\n"},{"id":"32642","messageId":"20070125213712.GC13874@spearce.org","threadId":"6527","inReplyTo":"7vmz46ajcq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-25T21:37:12Z","receivedAt":"2007-01-25T21:37:12Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> - This is purely style, but we seem to prefer %d instead of %i\n> elsewhere in the code (three existing offenders are\n> builtin-describe.c, receive-pack.c and sha1_file which we may\n> want to clean up for consistency).\n\nI'll send a cleanup patch then for these locations.\n \n> - How much damage are we talking about with this patch to\n> People's existing scripts? I expect they all extract the\n> hash from last -g (because they cannot rely on particular\n> convention in tagnames), but I am also worried if people are\n> expecting everything that comes before the last -g is the\n> whole tag.\n\nNo way to know for sure. I almost put this as an option\n(e.g. \"--include-distance\") but didn't want everyone to need to\nupdate their existing git-describe callers to obtain this new data.\nI would hope that people split on last -g to get at or remove the\ncommit SHA-1, but they probably are also assiming te tag name is\neverything to the left. Including the distance would certainly\nviolate that.\n\n-- \nShawn.\n"},{"id":"32644","messageId":"7v7ivaailb.fsf@assigned-by-dhcp.cox.net","threadId":"6527","inReplyTo":"7vmz46ajcq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-25T21:42:56Z","receivedAt":"2007-01-25T21:42:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> ---\n>> builtin-describe.c | 3 ++-\n>> 1 files changed, 2 insertions(+), 1 deletions(-)\n>>\n>> diff --git a/builtin-describe.c b/builtin-describe.c\n>> index e7b8f95..d8ff621 100644\n>> --- a/builtin-describe.c\n>> +++ b/builtin-describe.c\n>> @@ -189,7 +189,8 @@ 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>> +\tprintf(\"%s-%i-g%s\\n\", all_matches[0].name->path,\n>> +\t\t all_matches[0].depth,\n>> \t\t find_unique_abbrev(cmit->object.sha1, abbrev));\n>> \n>> \tif (!last_one)\n>\n> Two comments.\n>\n> - This is purely style, but we seem to prefer %d instead of %i\n> elsewhere in the code (three existing offenders are\n> builtin-describe.c, receive-pack.c and sha1_file which we may\n> want to clean up for consistency).\n>\n> - How much damage are we talking about with this patch to\n> People's existing scripts? I expect they all extract the\n> hash from last -g (because they cannot rely on particular\n> convention in tagnames), but I am also worried if people are\n> expecting everything that comes before the last -g is the\n> whole tag.\n\nActually there is a third one and a half.\n\n - We need to update the documentation to say what this new\n number means.\n\nIt's some number close to the number of revs since the named\ntag, but not exactly.\n\n $ git describe --debug 65ebe634 2>&1 | head -4\n searching to describe 65ebe634\n annotated 251 v2.6.20-rc5\n annotated 427 v2.6.20-rc4\n annotated 594 v2.6.20-rc3\n $ git rev-list v2.6.20-rc5..65ebe634 | wc -l\n 254\n $ git rev-list v2.6.20-rc4..65ebe634 | wc -l\n 430\n\nAnd it does not seem to be always \"minus 3\" either.\n"},{"id":"32645","messageId":"20070125214923.GD13874@spearce.org","threadId":"6527","inReplyTo":"7v7ivaailb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-25T21:49:23Z","receivedAt":"2007-01-25T21:49:23Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> - We need to update the documentation to say what this new\n> number means.\n\nIndeed; I apologize for forgetting to do that. At this point\nI'll wind up resending the patch to address everything so toss\nwhat you have.\n \n> It's some number close to the number of revs since the named\n> tag, but not exactly.\n> \n> $ git describe --debug 65ebe634 2>&1 | head -4\n> searching to describe 65ebe634\n> annotated 251 v2.6.20-rc5\n> annotated 427 v2.6.20-rc4\n> annotated 594 v2.6.20-rc3\n> $ git rev-list v2.6.20-rc5..65ebe634 | wc -l\n> 254\n> $ git rev-list v2.6.20-rc4..65ebe634 | wc -l\n> 430\n> \n> And it does not seem to be always \"minus 3\" either.\n\nWhat you skipped in the --debug output above was that we hit\nour internal possible tag limit (10 by default) and aborted\nwalking the revision chain. That's why we missed 3 revs in\nour counting. :)\n\nWe probably should make an option to enable the count, and\nif the count is enabled then we'll have to pickup counting\nwhere we left off and finish it out for the chosen tag so\nthe count is correct.\n\n-- \nShawn.\n"},{"id":"32659","messageId":"Pine.LNX.4.64.0701251830400.3021@xanadu.home","threadId":"6527","inReplyTo":"20070125214923.GD13874@spearce.org","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-25T23:32:01Z","receivedAt":"2007-01-25T23:32:01Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 25 Jan 2007, Shawn O. Pearce wrote:\n\n> We probably should make an option to enable the count, and\n> if the count is enabled then we'll have to pickup counting\n> where we left off and finish it out for the chosen tag so\n> the count is correct.\nPlease don't make it an option. This is too useful to require an \nadditional switch all the time.\n\n\nNicolas\n"},{"id":"32667","messageId":"7vmz4663xq.fsf@assigned-by-dhcp.cox.net","threadId":"6527","inReplyTo":"Pine.LNX.4.64.0701251830400.3021@xanadu.home","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-26T00:13:05Z","receivedAt":"2007-01-26T00:13:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Thu, 25 Jan 2007, Shawn O. Pearce wrote:\n>\n>> We probably should make an option to enable the count, and\n>> if the count is enabled then we'll have to pickup counting\n>> where we left off and finish it out for the chosen tag so\n>> the count is correct.\n>\n> Please don't make it an option. This is too useful to require an \n> additional switch all the time.\n\nHmph. And an option --no-number to disable this is probably not\nworth it, as it forces the existing scripts that wants the\ntagname to be updated to pass that new option. If the users\nneed to update their scripts anyway, they can sed/expr the\nnumber out just as easily as passing the new option.\n\nAnother backward incompatibility to mention in the release\nnotes. I guess it is not too big a deal but makes me feel\nuneasy.\n"},{"id":"32693","messageId":"38b2ab8a0701260052q517285e8l2505114a48d34558@mail.gmail.com","threadId":"6527","inReplyTo":"7vmz4663xq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-01-26T08:52:19Z","receivedAt":"2007-01-26T08:52:19Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On 1/26/07, Junio C Hamano wrote:\n> Another backward incompatibility to mention in the release\n> notes. I guess it is not too big a deal but makes me feel\n> uneasy.\n>\n\nSorry if I missed any discussions about that point but why not calling\nthe coming release 2.0 instead of 1.5 if this one implies some\nbackward incompabilities and a lot of change in the UI ?\n\nthanks\n-- \nFrancis\n"},{"id":"32697","messageId":"7vlkjq17sm.fsf@assigned-by-dhcp.cox.net","threadId":"6527","inReplyTo":"38b2ab8a0701260052q517285e8l2505114a48d34558@mail.gmail.com","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-26T09:00:57Z","receivedAt":"2007-01-26T09:00:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Francis Moreau\" writes:\n\n> On 1/26/07, Junio C Hamano wrote:\n>> Another backward incompatibility to mention in the release\n>> notes. I guess it is not too big a deal but makes me feel\n>> uneasy.\n>>\n>\n> Sorry if I missed any discussions about that point but why not calling\n> the coming release 2.0 instead of 1.5 if this one implies some\n> backward incompabilities and a lot of change in the UI ?\n\nBecause with the usual numbering the next normal feature release\nwould have been called 1.4.5, we said we would bump to 1.5 some\ntime ago.\n\nThere is no fundamental change between 1.4.4 series and the\nupcoming 1.5.0 -- only superficial ones. I do not think it\ndeserves a bump in the major version; well, at least I did not\nthink it would, when we first started talking about \"the new\nrelease whose main theme was usability enhancements\".\n"},{"id":"32705","messageId":"38b2ab8a0701260139w25d3e6c7ka8a0097f247f8421@mail.gmail.com","threadId":"6527","inReplyTo":"7vlkjq17sm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-01-26T09:39:10Z","receivedAt":"2007-01-26T09:39:10Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On 1/26/07, Junio C Hamano wrote:\n> There is no fundamental change between 1.4.4 series and the\n> upcoming 1.5.0 -- only superficial ones. I do not think it\n\nBut there are incompatibilities.\n\nAnother example, which may be a bad one since I unfortunately don't\nhave time to follow closely git's development: the internal of 'git\npull' has completely changed. If I clone a repo with git v1.4.x and I\npull in this repo with git v1.5.x, does it still works ?\n\nthanks\n-- \nFrancis\n"},{"id":"32710","messageId":"20070126095114.GA15905@spearce.org","threadId":"6527","inReplyTo":"38b2ab8a0701260139w25d3e6c7ka8a0097f247f8421@mail.gmail.com","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-26T09:51:14Z","receivedAt":"2007-01-26T09:51:14Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Francis Moreau wrote:\n> But there are incompatibilities.\n\nNothing really *that* major. Heck, that git-describe change is\nprobably one of the biggest, if not the biggest.\n \n> Another example, which may be a bad one since I unfortunately don't\n> have time to follow closely git's development: the internal of 'git\n> pull' has completely changed. If I clone a repo with git v1.4.x and I\n> pull in this repo with git v1.5.x, does it still works ?\n\nYes, of course. Just like before too.\n\nWhat's different is if you clone with 1.5.x, as we now default to the\nseperate remotes layout. This was an option in 1.4.x and earlier,\nits now the only way its done in 1.5.x.\n\n-- \nShawn.\n"},{"id":"32715","messageId":"200701261036.26012.andyparkins@gmail.com","threadId":"6527","inReplyTo":"7vmz4663xq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-26T10:36:18Z","receivedAt":"2007-01-26T10:36:18Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 January 26 00:13, Junio C Hamano wrote:\n\n> Hmph. And an option --no-number to disable this is probably not\n> worth it, as it forces the existing scripts that wants the\n> tagname to be updated to pass that new option. If the users\n> need to update their scripts anyway, they can sed/expr the\n> number out just as easily as passing the new option.\n\nActually, the more useful switch would be \"--tag-only\"; then\n\nx=$(git-describe HEAD | sed 's/-g*//')\n\nIn scripts could become\n\nx=$(git-describe --tag-only HEAD)\n\nThen, the suffix can be anything we want, and can change in the future without \naffecting these scripts.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"32734","messageId":"epcvsg$784$1@sea.gmane.org","threadId":"6527","inReplyTo":"20070125173954.GA13276@spearce.org","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-26T13:33:09Z","receivedAt":"2007-01-26T13:33:09Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nShawn O. Pearce wrote:\n\n> +       printf(\"%s-%i-g%s\\n\", all_matches[0].name->path,\n\nI'd rather use \"%s+%i-g%s\\n\" here...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32741","messageId":"200701261428.55838.andyparkins@gmail.com","threadId":"6527","inReplyTo":"200701261036.26012.andyparkins@gmail.com","subject":"[PATCH] If abbrev is set to zero in git-describe, don't add the unique suffix","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-26T14:28:55Z","receivedAt":"2007-01-26T14:28:55Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"When 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 \n---\n builtin-describe.c | 9 ++++++---\n 1 files changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex 4921eee..f3ac2d5 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 == 0)\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\t find_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 != 0 && (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.gc3537-dirty\n"},{"id":"32762","messageId":"20070126193736.GA7361@moooo.ath.cx","threadId":"6527","inReplyTo":"epcvsg$784$1@sea.gmane.org","subject":"Re: [PATCH 1/2] Teach git-describe to display distances from tags.","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-01-26T19:37:36Z","receivedAt":"2007-01-26T19:37:36Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Jakub Narebski wrote:\n> I'd rather use \"%s+%i-g%s\\n\" here...\nAck, this makes it much easier to recognise what this number is.\n"}]}