{"thread":{"id":"25178","subject":"can git-describe learn first-parent behavior?","startedAt":"2010-09-21T05:58:43Z","lastAt":"2010-09-22T17:45:29Z","messageCount":12,"participants":["Joshua Shrader","Michael J Gruber","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"151183","messageId":"AANLkTi=6o15y-6Q+tn40=hrPf9pmo+Y1Jd97hGxr5mH2@mail.gmail.com","threadId":"25178","inReplyTo":null,"subject":"can git-describe learn first-parent behavior?","fromName":"Joshua Shrader","fromEmail":"jshrader83@gmail.com","sentAt":"2010-09-21T05:58:43Z","receivedAt":"2010-09-21T05:58:43Z","isPatch":false,"sender":{"key":"jshrader83@gmail.com","avatar":null},"body":"This seems like it would be a rather useful feature.  Suppose a\nmaintenance branch, maint/v1.0, is forked from master, and the branch\npoint is tagged something like \"v1.0-stable\".  The next commit on\nmaster is tagged \"v2.0-base\", indicating that it is the first commit\nof the new release.  Suppose two releases are made - a release for\npublic consumption of version 1.0, and a release for internal testing\nfrom master (currently 2.0), and we want to embed the output of\ngit-describe into the builds.  If bugs were fixed on 1.0, and then 1.0\nwas merged into master, it seems perfectly possible to run\ngit-describe on master, but get the v1.0 tag in the output.\n\nIs this just a poor workflow?  Am I using git-describe incorrectly?\nOr, does a first-parent option to git-describe seem useful?\n\nThanks for the input.\n\nJosh\n"},{"id":"151194","messageId":"4C987C2E.3060001@drmicha.warpmail.net","threadId":"25178","inReplyTo":"AANLkTi=6o15y-6Q+tn40=hrPf9pmo+Y1Jd97hGxr5mH2@mail.gmail.com","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-21T09:34:38Z","receivedAt":"2010-09-21T09:34:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Joshua Shrader venit, vidit, dixit 21.09.2010 07:58:\n> This seems like it would be a rather useful feature.  Suppose a\n> maintenance branch, maint/v1.0, is forked from master, and the branch\n> point is tagged something like \"v1.0-stable\".  The next commit on\n> master is tagged \"v2.0-base\", indicating that it is the first commit\n> of the new release.  Suppose two releases are made - a release for\n> public consumption of version 1.0, and a release for internal testing\n> from master (currently 2.0), and we want to embed the output of\n> git-describe into the builds.  If bugs were fixed on 1.0, and then 1.0\n> was merged into master, it seems perfectly possible to run\n> git-describe on master, but get the v1.0 tag in the output.\n\nThe earlier tag (in terms of depth) wins, yes.\n \n> Is this just a poor workflow?  Am I using git-describe incorrectly?\n> Or, does a first-parent option to git-describe seem useful?\n> \n> Thanks for the input.\n\nIf you know you want to describe HEAD based on v2 tags you can use\n\ngit describe --match v2\\* --tags HEAD\n\n\"git describe\" does not use the revision walk machinery so that it does\nnot have the --first-parent option. I'm not sure how useful that is, but\nit's easy to implement.\n\nMichael\n"},{"id":"151195","messageId":"7d63bc1d2c7408090501bade7e7f8a9eb43cffb3.1285061563.git.git@drmicha.warpmail.net","threadId":"25178","inReplyTo":"4C987C2E.3060001@drmicha.warpmail.net","subject":"[RFC PATCH] git-describe: introduce --first-parent","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-21T09:35:28Z","receivedAt":"2010-09-21T09:35:28Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"so that git-describe searches first-parent history only when looking for\na named commit. This is useful for describing commits by tags on their\n\"main\" (first-parent) branch.\n\ngit describe --contains --first-parent is forbidden because git name-rev\n(which is called by that) favors first-parent transversal already,\nalthough not strictly so.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nNotes:\n    Is this considered useful? RFC because of lack of doc and test.\n    I consider it easier than (and different from) --match in some cases.\n\n builtin/describe.c |    8 +++++++-\n 1 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex 43caff2..6b2b599 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -22,6 +22,7 @@ static int tags;\t/* Allow lightweight tags */\n static int longformat;\n static int abbrev = DEFAULT_ABBREV;\n static int max_candidates = 10;\n+static int first_parent;\n static int found_names;\n static const char *pattern;\n static int always;\n@@ -302,7 +303,7 @@ static void describe(const char *arg, int last_one)\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\tparents = first_parent ? NULL : parents->next;\n \t\t}\n \t}\n \n@@ -380,6 +381,8 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\t\t   \"only consider tags matching <pattern>\"),\n \t\tOPT_BOOLEAN(0, \"always\",     &always,\n \t\t\t   \"show abbreviated commit object as fallback\"),\n+\t\tOPT_BOOLEAN(0, \"first-parent\",     &first_parent,\n+\t\t\t   \"follow first parents only\"),\n \t\t{OPTION_STRING, 0, \"dirty\",  &dirty, \"mark\",\n \t\t\t   \"append <mark> on dirty working tree (default: \\\"-dirty\\\")\",\n \t\t PARSE_OPT_OPTARG, NULL, (intptr_t) \"-dirty\"},\n@@ -397,6 +400,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \tif (longformat && abbrev == 0)\n \t\tdie(\"--long is incompatible with --abbrev=0\");\n \n+\tif (contains && first-parent)\n+\t\tdie(\"--contains is incompatible with --first-parent\");\n+\n \tif (contains) {\n \t\tconst char **args = xmalloc((7 + argc) * sizeof(char *));\n \t\tint i = 0;\n-- \n1.7.3.234.g7bba3\n"},{"id":"151197","messageId":"4C98830A.70203@viscovery.net","threadId":"25178","inReplyTo":"4C987C2E.3060001@drmicha.warpmail.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-09-21T10:03:54Z","receivedAt":"2010-09-21T10:03:54Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/21/2010 11:34, schrieb Michael J Gruber:\n> The earlier tag (in terms of depth) wins, yes.\n\nDoes it? Then explain this result:\n\ngit describe e5498e8a^2 e5498e8a^1~24 e5498e8a\nv1.7.0.7\nv1.7.1.1\nv1.7.1.1-38-ge5498e8\n\nv1.7.1.1 is 25 commits away, while v1.7.0.7 is a parent (the second).\n\nAFAICS, git-describe does The Right Thing (--first-parent).\n\n-- Hannes\n"},{"id":"151205","messageId":"4C989BBD.80106@drmicha.warpmail.net","threadId":"25178","inReplyTo":"4C98830A.70203@viscovery.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-21T11:49:17Z","receivedAt":"2010-09-21T11:49:17Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 21.09.2010 12:03:\n> Am 9/21/2010 11:34, schrieb Michael J Gruber:\n>> The earlier tag (in terms of depth) wins, yes.\n> \n> Does it? Then explain this result:\n> \n> git describe e5498e8a^2 e5498e8a^1~24 e5498e8a\n> v1.7.0.7\n> v1.7.1.1\n> v1.7.1.1-38-ge5498e8\n> \n> v1.7.1.1 is 25 commits away, while v1.7.0.7 is a parent (the second).\n> \n> AFAICS, git-describe does The Right Thing (--first-parent).\n\nI'm not saying it does the wrong thing. I'm saying it does not do\n--first-parent but depth priority (where depth is a bit complicated),\nwhich may or may not be the same as first-parent transversal/priority.\nYou picked one case where they coincide:\n\ngit describe --debug e5498e8a^2 e5498e8a^2~24 e5498e8a\nv1.7.0.7\nv1.7.0.5\nsearching to describe e5498e8a\n annotated         38 v1.7.1.1\n annotated        252 v1.7.1\n annotated        268 v1.7.1-rc2\n annotated        318 v1.7.1-rc1\n annotated        355 v1.7.1-rc0\n annotated        478 v1.7.0.7\n annotated        492 v1.7.0.6\n annotated        512 v1.7.0.5\n annotated        539 v1.7.0.4\n annotated        564 v1.7.0.3\ntraversed 1267 commits\nmore than 10 tags found; listed 10 most recent\ngave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\nv1.7.1.1-38-ge5498e8\n\nv1.7.1.1 clearly wins by depth priority.\n\n\nIn an example like Joshua's, it is obviously not the first parent which\nwins by default:\n\n* 771c6c7 (HEAD, master) more_development\n*   88b63bd Merge branch 'maint'\n|\\\n| * d99fb44 (tag: v1.1-stable, maint) v1.1-stable\n* | c2f7480 development\n* | 9480bca (tag: v2.0-base) v2.0-base\n|/\n* 31e78ef (tag: v1.0-stable) v1.0-stable\n\ngit describe --debug --tags  HEAD\nsearching to describe HEAD\n lightweight        4 v1.1-stable\n lightweight        4 v2.0-base\n lightweight        5 v1.0-stable\ntraversed 6 commits\nv1.1-stable-4-g771c6c7\n\ngit describe --debug --tags --match v2\\* HEAD\nsearching to describe HEAD\n lightweight        4 v2.0-base\ntraversed 6 commits\nv2.0-base-4-g771c6c7\n\ngit describe --debug --tags --first-parent HEAD\nsearching to describe HEAD\n lightweight        3 v2.0-base\n lightweight        4 v1.0-stable\ntraversed 5 commits\nv2.0-base-3-g771c6c7\n\nThe latter is with my RFC PATCH, of course.\n\nNote that without the commit \"development\", v2.0-base wins even in the\nfirst case, even though this does not change the first-parent relationships.\n\nCheers\nMichael\n"},{"id":"151206","messageId":"4C989E6B.1070703@viscovery.net","threadId":"25178","inReplyTo":"4C989BBD.80106@drmicha.warpmail.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-09-21T12:00:43Z","receivedAt":"2010-09-21T12:00:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/21/2010 13:49, schrieb Michael J Gruber:\n> Johannes Sixt venit, vidit, dixit 21.09.2010 12:03:\n>> git describe e5498e8a^2 e5498e8a^1~24 e5498e8a\n>> v1.7.0.7\n>> v1.7.1.1\n>> v1.7.1.1-38-ge5498e8\n>>\n>> v1.7.1.1 is 25 commits away, while v1.7.0.7 is a parent (the second).\n>>\n>> AFAICS, git-describe does The Right Thing (--first-parent).\n> \n> I'm not saying it does the wrong thing. I'm saying it does not do\n> --first-parent but depth priority (where depth is a bit complicated),\n> which may or may not be the same as first-parent transversal/priority.\n> You picked one case where they coincide:\n> \n> git describe --debug e5498e8a^2 e5498e8a^2~24 e5498e8a\n> v1.7.0.7\n> v1.7.0.5\n\nThis should be \"v1.7.1.1\", no?\n\n> searching to describe e5498e8a\n>  annotated         38 v1.7.1.1\n>  annotated        252 v1.7.1\n>  annotated        268 v1.7.1-rc2\n>  annotated        318 v1.7.1-rc1\n>  annotated        355 v1.7.1-rc0\n>  annotated        478 v1.7.0.7\n>  annotated        492 v1.7.0.6\n>  annotated        512 v1.7.0.5\n>  annotated        539 v1.7.0.4\n>  annotated        564 v1.7.0.3\n> traversed 1267 commits\n> more than 10 tags found; listed 10 most recent\n> gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\n> v1.7.1.1-38-ge5498e8\n> \n> v1.7.1.1 clearly wins by depth priority.\n\nIf \"depth priority\" is not the shortest ancestry path (and it obviously is\nnot given the numbers above), what is it then, and why does it not work\nwith Joshua's example? Wouldn't it be better to make it Just Work instead\nof adding a workaround that has to be enabled manually?\n\n-- Hannes\n"},{"id":"151209","messageId":"4C98A0B7.9050501@drmicha.warpmail.net","threadId":"25178","inReplyTo":"4C989E6B.1070703@viscovery.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-21T12:10:31Z","receivedAt":"2010-09-21T12:10:31Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 21.09.2010 14:00:\n> Am 9/21/2010 13:49, schrieb Michael J Gruber:\n>> Johannes Sixt venit, vidit, dixit 21.09.2010 12:03:\n>>> git describe e5498e8a^2 e5498e8a^1~24 e5498e8a\n>>> v1.7.0.7\n>>> v1.7.1.1\n>>> v1.7.1.1-38-ge5498e8\n>>>\n>>> v1.7.1.1 is 25 commits away, while v1.7.0.7 is a parent (the second).\n>>>\n>>> AFAICS, git-describe does The Right Thing (--first-parent).\n>>\n>> I'm not saying it does the wrong thing. I'm saying it does not do\n>> --first-parent but depth priority (where depth is a bit complicated),\n>> which may or may not be the same as first-parent transversal/priority.\n>> You picked one case where they coincide:\n>>\n>> git describe --debug e5498e8a^2 e5498e8a^2~24 e5498e8a\n>> v1.7.0.7\n>> v1.7.0.5\n> \n> This should be \"v1.7.1.1\", no?\n\nWell, e5498e8a^2~24 == v1.7.0.5 and e5498e8a^1~24 == v1.7.1.1.\nThe copy&paste from your e-mail was not exactly helped by Thunderbirds\nconversion of ^2, ^1 into exponents... In any case, the numbers below\nare what matters:\n\n> \n>> searching to describe e5498e8a\n>>  annotated         38 v1.7.1.1\n>>  annotated        252 v1.7.1\n>>  annotated        268 v1.7.1-rc2\n>>  annotated        318 v1.7.1-rc1\n>>  annotated        355 v1.7.1-rc0\n>>  annotated        478 v1.7.0.7\n>>  annotated        492 v1.7.0.6\n>>  annotated        512 v1.7.0.5\n>>  annotated        539 v1.7.0.4\n>>  annotated        564 v1.7.0.3\n>> traversed 1267 commits\n>> more than 10 tags found; listed 10 most recent\n>> gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\n>> v1.7.1.1-38-ge5498e8\n>>\n>> v1.7.1.1 clearly wins by depth priority.\n> \n> If \"depth priority\" is not the shortest ancestry path (and it obviously is\n> not given the numbers above), what is it then, and why does it not work\n> with Joshua's example? Wouldn't it be better to make it Just Work instead\n> of adding a workaround that has to be enabled manually?\n\nI don't consider the existing behaviour wrong, though it may be a bit\ntough to figure out. It may even be that the depth calculation has an\noff-by-1 error which leads to this behaviour.\n\nConsequently, I don't consider --first-parent a workaround. Note that\nwith --first-parent, tags on other branches are not even considered so\nthat you can be sure to get a first parent tag or none.\n\nDo you really think that changing the algorithm would be accepted? In\nany case, at most that would lead to prioritizing first parent tags\nunconditionally but still resorting to other tags when there are no\nfirst-parent tags.\n\nMichael\n"},{"id":"151210","messageId":"4C98A645.8070601@viscovery.net","threadId":"25178","inReplyTo":"4C98A0B7.9050501@drmicha.warpmail.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-09-21T12:34:13Z","receivedAt":"2010-09-21T12:34:13Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/21/2010 14:10, schrieb Michael J Gruber:\n> Johannes Sixt venit, vidit, dixit 21.09.2010 14:00:\n>> Am 9/21/2010 13:49, schrieb Michael J Gruber:\n>>> searching to describe e5498e8a\n>>>  annotated         38 v1.7.1.1\n>>>  annotated        252 v1.7.1\n>>>  annotated        268 v1.7.1-rc2\n>>>  annotated        318 v1.7.1-rc1\n>>>  annotated        355 v1.7.1-rc0\n>>>  annotated        478 v1.7.0.7\n>>>  annotated        492 v1.7.0.6\n>>>  annotated        512 v1.7.0.5\n>>>  annotated        539 v1.7.0.4\n>>>  annotated        564 v1.7.0.3\n>>> traversed 1267 commits\n>>> more than 10 tags found; listed 10 most recent\n>>> gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\n>>> v1.7.1.1-38-ge5498e8\n>>>\n>>> v1.7.1.1 clearly wins by depth priority.\n>>\n>> If \"depth priority\" is not the shortest ancestry path (and it obviously is\n>> not given the numbers above), what is it then, and why does it not work\n>> with Joshua's example? Wouldn't it be better to make it Just Work instead\n>> of adding a workaround that has to be enabled manually?\n> \n> I don't consider the existing behaviour wrong, though it may be a bit\n> tough to figure out. It may even be that the depth calculation has an\n> off-by-1 error which leads to this behaviour.\n\nI faintly recall that the current behavior was already made\n--first-parent-like on purpose, exactly for cases like Joshua's and the\none I cited. Why does it work with mine, but not with Joshua's?\n\nNotice that v1.7.0.7 is an immediate parent of e5498e8a, but still its\ncalculated \"depth\" is much higher than for v1.7.1.1, which is 25 commits\ndown in the history. Why? Why isn't it the same with Joshua's history? Is\nit due to the commit dates? Or the tag dates?\n\n-- Hannes\n"},{"id":"151220","messageId":"4C98CEA1.2050405@drmicha.warpmail.net","threadId":"25178","inReplyTo":"4C98A645.8070601@viscovery.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-21T15:26:25Z","receivedAt":"2010-09-21T15:26:25Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 21.09.2010 14:34:\n> Am 9/21/2010 14:10, schrieb Michael J Gruber:\n>> Johannes Sixt venit, vidit, dixit 21.09.2010 14:00:\n>>> Am 9/21/2010 13:49, schrieb Michael J Gruber:\n>>>> searching to describe e5498e8a\n>>>>  annotated         38 v1.7.1.1\n>>>>  annotated        252 v1.7.1\n>>>>  annotated        268 v1.7.1-rc2\n>>>>  annotated        318 v1.7.1-rc1\n>>>>  annotated        355 v1.7.1-rc0\n>>>>  annotated        478 v1.7.0.7\n>>>>  annotated        492 v1.7.0.6\n>>>>  annotated        512 v1.7.0.5\n>>>>  annotated        539 v1.7.0.4\n>>>>  annotated        564 v1.7.0.3\n>>>> traversed 1267 commits\n>>>> more than 10 tags found; listed 10 most recent\n>>>> gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\n>>>> v1.7.1.1-38-ge5498e8\n>>>>\n>>>> v1.7.1.1 clearly wins by depth priority.\n>>>\n>>> If \"depth priority\" is not the shortest ancestry path (and it obviously is\n>>> not given the numbers above), what is it then, and why does it not work\n>>> with Joshua's example? Wouldn't it be better to make it Just Work instead\n>>> of adding a workaround that has to be enabled manually?\n>>\n>> I don't consider the existing behaviour wrong, though it may be a bit\n>> tough to figure out. It may even be that the depth calculation has an\n>> off-by-1 error which leads to this behaviour.\n> \n> I faintly recall that the current behavior was already made\n\nBetter faintly than faintingly ;)\n\n> --first-parent-like on purpose, exactly for cases like Joshua's and the\n> one I cited. Why does it work with mine, but not with Joshua's?\n> \n> Notice that v1.7.0.7 is an immediate parent of e5498e8a, but still its\n> calculated \"depth\" is much higher than for v1.7.1.1, which is 25 commits\n> down in the history. Why? Why isn't it the same with Joshua's history? Is\n> it due to the commit dates? Or the tag dates?\n\n\nBy experimentation (inserting additional tag-less commits, not changing\ntopology), I can make v2.0-base have the same, lower or higher depth\nthan v1.1-stable.\n\nIn fact, the (commit) date order is important here: For describing\n<commit>, \"describe\" builds a 1 item list with commit, pops it, inserts\nits parents in date order (!), looks at each item in that order, in each\nstep again inserting the parents in date order. So, it's really that the\nbranch with more newer commits wins (this is a lousy description, but\nyou get the idea).\n\nReading commit messages like 80dbae makes me think that this was\nintended; and it is completely different from a first-parent approach.\nSo I think the default really is a good default as is, and first-parent\nis useful and different in some cases.\n\nMichael\n"},{"id":"151238","messageId":"AANLkTinDYae7yxSaRKNwOvkRe3yQ2GCBT=tiXhDe7NVR@mail.gmail.com","threadId":"25178","inReplyTo":"4C98CEA1.2050405@drmicha.warpmail.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Joshua Shrader","fromEmail":"jshrader83@gmail.com","sentAt":"2010-09-21T19:57:07Z","receivedAt":"2010-09-21T19:57:07Z","isPatch":false,"sender":{"key":"jshrader83@gmail.com","avatar":null},"body":"I think I need to apologize to the list.  I did not actually observe\nwhat I had stated in my original post.  Given the description (and my\npossibly naive understanding) of git-describe, I hypothesized that\nwhat I originally stated was possible. If git-describe is in fact\nimplemented with a first-parent-like behavior, as some people believe\nto be true, then I believe it is working correctly - I've seen nothing\nto the contrary.  However, I do believe that the documentation is\nunclear if this is the case.  My interpretation of \"depth,\" which I\nbelieve to be consistent with the graph-theoretical definition, does\nimply that what I stated could happen.\n\n\nOn Tue, Sep 21, 2010 at 11:26 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Johannes Sixt venit, vidit, dixit 21.09.2010 14:34:\n>> Am 9/21/2010 14:10, schrieb Michael J Gruber:\n>>> Johannes Sixt venit, vidit, dixit 21.09.2010 14:00:\n>>>> Am 9/21/2010 13:49, schrieb Michael J Gruber:\n>>>>> searching to describe e5498e8a\n>>>>>  annotated         38 v1.7.1.1\n>>>>>  annotated        252 v1.7.1\n>>>>>  annotated        268 v1.7.1-rc2\n>>>>>  annotated        318 v1.7.1-rc1\n>>>>>  annotated        355 v1.7.1-rc0\n>>>>>  annotated        478 v1.7.0.7\n>>>>>  annotated        492 v1.7.0.6\n>>>>>  annotated        512 v1.7.0.5\n>>>>>  annotated        539 v1.7.0.4\n>>>>>  annotated        564 v1.7.0.3\n>>>>> traversed 1267 commits\n>>>>> more than 10 tags found; listed 10 most recent\n>>>>> gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7\n>>>>> v1.7.1.1-38-ge5498e8\n>>>>>\n>>>>> v1.7.1.1 clearly wins by depth priority.\n>>>>\n>>>> If \"depth priority\" is not the shortest ancestry path (and it obviously is\n>>>> not given the numbers above), what is it then, and why does it not work\n>>>> with Joshua's example? Wouldn't it be better to make it Just Work instead\n>>>> of adding a workaround that has to be enabled manually?\n>>>\n>>> I don't consider the existing behaviour wrong, though it may be a bit\n>>> tough to figure out. It may even be that the depth calculation has an\n>>> off-by-1 error which leads to this behaviour.\n>>\n>> I faintly recall that the current behavior was already made\n>\n> Better faintly than faintingly ;)\n>\n>> --first-parent-like on purpose, exactly for cases like Joshua's and the\n>> one I cited. Why does it work with mine, but not with Joshua's?\n>>\n>> Notice that v1.7.0.7 is an immediate parent of e5498e8a, but still its\n>> calculated \"depth\" is much higher than for v1.7.1.1, which is 25 commits\n>> down in the history. Why? Why isn't it the same with Joshua's history? Is\n>> it due to the commit dates? Or the tag dates?\n>\n>\n> By experimentation (inserting additional tag-less commits, not changing\n> topology), I can make v2.0-base have the same, lower or higher depth\n> than v1.1-stable.\n>\n> In fact, the (commit) date order is important here: For describing\n> <commit>, \"describe\" builds a 1 item list with commit, pops it, inserts\n> its parents in date order (!), looks at each item in that order, in each\n> step again inserting the parents in date order. So, it's really that the\n> branch with more newer commits wins (this is a lousy description, but\n> you get the idea).\n>\n> Reading commit messages like 80dbae makes me think that this was\n> intended; and it is completely different from a first-parent approach.\n> So I think the default really is a good default as is, and first-parent\n> is useful and different in some cases.\n>\n> Michael\n>\n"},{"id":"151277","messageId":"4C99A7BB.50401@drmicha.warpmail.net","threadId":"25178","inReplyTo":"AANLkTinDYae7yxSaRKNwOvkRe3yQ2GCBT=tiXhDe7NVR@mail.gmail.com","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-22T06:52:43Z","receivedAt":"2010-09-22T06:52:43Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Joshua Shrader venit, vidit, dixit 21.09.2010 21:57:\n> I think I need to apologize to the list.  I did not actually observe\n> what I had stated in my original post.  Given the description (and my\n> possibly naive understanding) of git-describe, I hypothesized that\n> what I originally stated was possible. If git-describe is in fact\n> implemented with a first-parent-like behavior, as some people believe\n> to be true, then I believe it is working correctly - I've seen nothing\n> to the contrary.  However, I do believe that the documentation is\n> unclear if this is the case.  My interpretation of \"depth,\" which I\n> believe to be consistent with the graph-theoretical definition, does\n> imply that what I stated could happen.\n\nJosh, no need to apologize. You simply tried to understand \"git\ndescribe\". The mere fact that a Git long time contributor (J6t) and an\noccasional contributor (I) are discussing \"git describe\"'s behaviour\ntells you that it can't be that easy ;)\n\nThe man page says \"most recent tag\", and that is true, but with a\ndefinition of \"most recent\" that you wouldn't expect. The description\nthere under \"Search Strategy\" is wrong, and has been at least since\n80dbae03. I'll try to come up with a better explanation fit for the man\npage, possibly after writing some more tests.\n\nThe intended behaviour is explained really well in Shawn's commit\nmessage for 80dbae03. And if you look at the algorithm you see that the\norder of the parents (as stored in a merge commit), in particular\nfirst-parent relationship plays no role at all. The algo takes all\nparents and inserts them in date order into a list to be looped over\nafterwards.\n\nThe more I understand the algo the more I realize that --first-parent is\nuseful and completely different, and that I can optimize more in my patch.\n\nCheers\nMichael\n"},{"id":"151302","messageId":"AANLkTimMggJtWNifuRCcVCEZ5NSjhdc9dEjftkOtjUOu@mail.gmail.com","threadId":"25178","inReplyTo":"4C99A7BB.50401@drmicha.warpmail.net","subject":"Re: can git-describe learn first-parent behavior?","fromName":"Joshua Shrader","fromEmail":"jshrader83@gmail.com","sentAt":"2010-09-22T17:45:29Z","receivedAt":"2010-09-22T17:45:29Z","isPatch":false,"sender":{"key":"jshrader83@gmail.com","avatar":null},"body":"Thanks for the response.  Since my last message, I have been able to\nget a tag on the v1.0 branch (although not the original v1.0-stable\ntag) to appear in the git describe output when run on v1.1 head, and\nthus I do think a --first-parent option would be useful.\n\nOn Wed, Sep 22, 2010 at 2:52 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Joshua Shrader venit, vidit, dixit 21.09.2010 21:57:\n>> I think I need to apologize to the list.  I did not actually observe\n>> what I had stated in my original post.  Given the description (and my\n>> possibly naive understanding) of git-describe, I hypothesized that\n>> what I originally stated was possible. If git-describe is in fact\n>> implemented with a first-parent-like behavior, as some people believe\n>> to be true, then I believe it is working correctly - I've seen nothing\n>> to the contrary.  However, I do believe that the documentation is\n>> unclear if this is the case.  My interpretation of \"depth,\" which I\n>> believe to be consistent with the graph-theoretical definition, does\n>> imply that what I stated could happen.\n>\n> Josh, no need to apologize. You simply tried to understand \"git\n> describe\". The mere fact that a Git long time contributor (J6t) and an\n> occasional contributor (I) are discussing \"git describe\"'s behaviour\n> tells you that it can't be that easy ;)\n>\n> The man page says \"most recent tag\", and that is true, but with a\n> definition of \"most recent\" that you wouldn't expect. The description\n> there under \"Search Strategy\" is wrong, and has been at least since\n> 80dbae03. I'll try to come up with a better explanation fit for the man\n> page, possibly after writing some more tests.\n>\n> The intended behaviour is explained really well in Shawn's commit\n> message for 80dbae03. And if you look at the algorithm you see that the\n> order of the parents (as stored in a merge commit), in particular\n> first-parent relationship plays no role at all. The algo takes all\n> parents and inserts them in date order into a list to be looped over\n> afterwards.\n>\n> The more I understand the algo the more I realize that --first-parent is\n> useful and completely different, and that I can optimize more in my patch.\n>\n> Cheers\n> Michael\n>\n"}]}