{"thread":{"id":"36427","subject":"[PATCH] tag: add -i and --introduced modifier for --contains","startedAt":"2014-04-16T20:58:58Z","lastAt":"2014-04-22T17:58:08Z","messageCount":16,"participants":["Luis R. Rodriguez","Junio C Hamano","Andreas Schwab","Jeff King","W. Trevor King","Jan Kara"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"238981","messageId":"1397681938-18594-1-git-send-email-mcgrof@do-not-panic.com","threadId":"36427","inReplyTo":null,"subject":"[PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Luis R. Rodriguez","fromEmail":"mcgrof@do-not-panic.com","sentAt":"2014-04-16T20:58:58Z","receivedAt":"2014-04-16T20:58:58Z","isPatch":true,"sender":{"key":"mcgrof@do-not-panic.com","avatar":null},"body":"From: \"Luis R. Rodriguez\" <mcgrof@suse.com>\n\nUpstream Linux kernel commit c5905afb was introduced on v3.4 but\ngit describe --contains yields v3.5 while if we use git to look\nfor the first parent with git describe --first-parent yields\nv3.3. The reason for this seems to be that the merge commit that\nintroduced c5905afb was based on v3.3. At least for --contains\nits unclear to me why we get v3.5, the result is not intuitive,\nas for --first-parent the issue is that the first parent actually\n*is* v3.3. The easiest way to address this it to rely on on the\ngit tag --contains implmenetation and add a modifier that specifies\nyou want the tag that first introduced the specified commit.\n\nmcgrof@ergon ~/linux (git::master)$ git tag -i --contains c5905afb\nv3.4\n\nmcgrof@ergon ~/linux (git::master)$ git tag --introduced --contains c5905afb\nv3.4\n\nCc: Jiri Slaby <jslaby@suse.cz>\nCc: Andreas Schwab <schwab@suse.de>\nCc: Jan Kara <jack@suse.cz>\nSigned-off-by: Luis R. Rodriguez <mcgrof@suse.com>\n---\n builtin/tag.c | 21 ++++++++++++++++-----\n 1 file changed, 16 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin/tag.c b/builtin/tag.c\nindex 6c7c6bd..65a939b 100644\n--- a/builtin/tag.c\n+++ b/builtin/tag.c\n@@ -21,7 +21,7 @@\n static const char * const git_tag_usage[] = {\n \tN_(\"git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]\"),\n \tN_(\"git tag -d <tagname>...\"),\n-\tN_(\"git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>] \"\n+\tN_(\"git tag -l [-n[<num>]] [--contains <commit>] [ -i | --introduced --contains <commit> ] [--points-at <object>] \"\n \t\t\"\\n\\t\\t[<pattern>...]\"),\n \tN_(\"git tag -v <tagname>...\"),\n \tNULL\n@@ -195,13 +195,18 @@ static int sort_by_version(const void *a_, const void *b_)\n }\n \n static int list_tags(const char **patterns, int lines,\n-\t\t     struct commit_list *with_commit, int sort)\n+\t\t     struct commit_list *with_commit, int sort,\n+\t\t     int introduced)\n {\n \tstruct tag_filter filter;\n \n \tfilter.patterns = patterns;\n \tfilter.lines = lines;\n-\tfilter.sort = sort;\n+\tif (introduced) {\n+\t\tsort = VERCMP_SORT;\n+\t\tfilter.sort = sort;\n+\t} else\n+\t\tfilter.sort = sort;\n \tfilter.with_commit = with_commit;\n \tmemset(&filter.tags, 0, sizeof(filter.tags));\n \tfilter.tags.strdup_strings = 1;\n@@ -216,8 +221,11 @@ static int list_tags(const char **patterns, int lines,\n \t\t\tfor (i = filter.tags.nr - 1; i >= 0; i--)\n \t\t\t\tprintf(\"%s\\n\", filter.tags.items[i].string);\n \t\telse\n-\t\t\tfor (i = 0; i < filter.tags.nr; i++)\n+\t\t\tfor (i = 0; i < filter.tags.nr; i++) {\n \t\t\t\tprintf(\"%s\\n\", filter.tags.items[i].string);\n+\t\t\t\tif (introduced)\n+\t\t\t\t\tbreak;\n+\t\t\t}\n \t\tstring_list_clear(&filter.tags, 0);\n \t}\n \treturn 0;\n@@ -493,6 +501,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \tchar *cleanup_arg = NULL;\n \tint annotate = 0, force = 0, lines = -1;\n \tint cmdmode = 0, sort = 0;\n+\tint introduced = 0;\n \tconst char *msgfile = NULL, *keyid = NULL;\n \tstruct msg_arg msg = { 0, STRBUF_INIT };\n \tstruct commit_list *with_commit = NULL;\n@@ -511,6 +520,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \t\t\t     N_(\"tag message\"), parse_msg_arg),\n \t\tOPT_FILENAME('F', \"file\", &msgfile, N_(\"read message from file\")),\n \t\tOPT_BOOL('s', \"sign\", &opt.sign, N_(\"annotated and GPG-signed tag\")),\n+\t\tOPT_BOOL('i', \"introduced\", &introduced, N_(\"print the first tag that introduced the commit\")),\n \t\tOPT_STRING(0, \"cleanup\", &cleanup_arg, N_(\"mode\"),\n \t\t\tN_(\"how to strip spaces and #comments from message\")),\n \t\tOPT_STRING('u', \"local-user\", &keyid, N_(\"key-id\"),\n@@ -576,7 +586,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \t\t}\n \t\tif (lines != -1 && sort)\n \t\t\tdie(_(\"--sort and -n are incompatible\"));\n-\t\tret = list_tags(argv, lines == -1 ? 0 : lines, with_commit, sort);\n+\t\tret = list_tags(argv, lines == -1 ? 0 : lines, with_commit,\n+\t\t\t\tsort, introduced);\n \t\tif (column_active(colopts))\n \t\t\tstop_column_filter();\n \t\treturn ret;\n-- \n1.9.0\n"},{"id":"238985","messageId":"xmqqppkhexw3.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"1397681938-18594-1-git-send-email-mcgrof@do-not-panic.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-16T22:02:20Z","receivedAt":"2014-04-16T22:02:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n\n> From: \"Luis R. Rodriguez\" <mcgrof@suse.com>\n>\n> Upstream Linux kernel commit c5905afb was introduced on v3.4 but\n> git describe --contains yields v3.5\n\nActually, \"describe --contains\" should yield v3.5-rc1~120^3~76^2,\nnot v3.5.\n\nAnd you are right that the commit is contained in v3.4, so we also\nshould be able to describe it as v3.4~479^2~9^2 as well.\n\nAnd between v3.4 and v3.5-rc1, the latter is a closer anchor point\nfor that commit (v3.5-rc1 only needs about 200 hops to reach the\ncommit, while from v3.4 you would need close to 500 hops), hence we\nend up picking the latter as \"a better answer\".\n\nNow, with the explanation of how/why this happens behind us, I see\ntwo possible issues with this patch:\n\n - The reason a human-user rejects v3.5-rc1~120^3~76^2 as the\n   solution and favor v3.4~479^2~9^2 could be because of the -rc1\n   part in the answer.  Perhaps we would want an option that affects\n   which tags are to be used (and which tags are to be excluded) as\n   anchoring points?\n\n - If we are truly interested in finding out the \"earliest tag that\n   contains the given commit\", shouldn't we be ignoring the tagname\n   and go with the tag with the oldest timestamp?  After all, there\n   may be a fix merged to v7.0 first on April 1st, and then on a\n   later date the same fix may be merged to the maintenance track to\n   be tagged as v6.9.1 on May 5th, and in such a case, wouldn't you\n   want to say that the fix first appeared on v7.0 on April 1st,\n   instead of on May 5th?\n\nThanks.\n"},{"id":"238988","messageId":"CAB=NE6VvDrMQ4ybF10MpXM-2672OdUTC_Rp2mdO3a5fuo1-H1Q@mail.gmail.com","threadId":"36427","inReplyTo":"xmqqppkhexw3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Luis R. Rodriguez","fromEmail":"mcgrof@do-not-panic.com","sentAt":"2014-04-16T22:35:07Z","receivedAt":"2014-04-16T22:35:07Z","isPatch":true,"sender":{"key":"mcgrof@do-not-panic.com","avatar":null},"body":"On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n>\n>> From: \"Luis R. Rodriguez\" <mcgrof@suse.com>\n>>\n>> Upstream Linux kernel commit c5905afb was introduced on v3.4 but\n>> git describe --contains yields v3.5\n>\n> Actually, \"describe --contains\" should yield v3.5-rc1~120^3~76^2,\n> not v3.5.\n\nYes, indeed thanks, sorry I should have been explicit.\n\n> And you are right that the commit is contained in v3.4, so we also\n> should be able to describe it as v3.4~479^2~9^2 as well.\n\nThat'd be swell :)\n\n> And between v3.4 and v3.5-rc1, the latter is a closer anchor point\n> for that commit (v3.5-rc1 only needs about 200 hops to reach the\n> commit, while from v3.4 you would need close to 500 hops),\n\nAh! Thanks for explaining this mysterious puzzle to me. I'm a bit\nperplexed why still. Can I trouble you for a little elaboration here?\nHow could one view from a commit merged on v3.4 possibly yield more\ncommits to v3.4 than to v3.5 ? Is it because it starts counting on the\nmerge's parent (v3.3) ?\n\n> hence we\n> end up picking the latter as \"a better answer\".\n>\n> Now, with the explanation of how/why this happens behind us, I see\n> two possible issues with this patch:\n>\n>  - The reason a human-user rejects v3.5-rc1~120^3~76^2 as the\n>    solution and favor v3.4~479^2~9^2 could be because of the -rc1\n>    part in the answer.  Perhaps we would want an option that affects\n>    which tags are to be used (and which tags are to be excluded) as\n>    anchoring points?\n\nI'd take an rc release as a blessed point too so not sure, and come to\nthink of it I'm not a bit perplexed why the results for my change did\nnot yield an rc1 as well.\n\n>  - If we are truly interested in finding out the \"earliest tag that\n>    contains the given commit\", shouldn't we be ignoring the tagname\n>    and go with the tag with the oldest timestamp?  After all, there\n>    may be a fix merged to v7.0 first on April 1st, and then on a\n>    later date the same fix may be merged to the maintenance track to\n>    be tagged as v6.9.1 on May 5th,\n\nAt least for Linux linux-3.X.y branches (one example linux-3.4.y) on\nlinux-stable has different commit IDs from patches cherry picked from\nLinus' tree, and that patch just referneces the upstream commit from\nLinus' tree on the commit log, but nothing more.\n\n> and in such a case, wouldn't you  want to say that the fix first appeared on v7.0 on April 1st,\n> instead of on May 5th?\n\nSure, but I'd expect the folks maintaining v6.9.x would just refer to\nthe upstream commit ID from v7.0.\n\n  Luis\n"},{"id":"239010","messageId":"mvm8ur42zn6.fsf@hawking.suse.de","threadId":"36427","inReplyTo":"xmqqppkhexw3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Andreas Schwab","fromEmail":"schwab@suse.de","sentAt":"2014-04-17T07:17:33Z","receivedAt":"2014-04-17T07:17:33Z","isPatch":true,"sender":{"key":"schwab@suse.de","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> And you are right that the commit is contained in v3.4, so we also\n> should be able to describe it as v3.4~479^2~9^2 as well.\n\nIMHO it should be described as v3.4-rc1~192^2~9^2, which is what git\ndescribe --contains --match=v3.4\\* returns.  This path is only a few\ncommits longer than v3.5-rc1~120^3~76^2.\n\nAndreas.\n\n-- \nAndreas Schwab, SUSE Labs, schwab@suse.de\nGPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7\n\"And now for something completely different.\"\n"},{"id":"239021","messageId":"xmqqfvlbga4r.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"CAB=NE6VvDrMQ4ybF10MpXM-2672OdUTC_Rp2mdO3a5fuo1-H1Q@mail.gmail.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-17T17:04:52Z","receivedAt":"2014-04-17T17:04:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n\n>> And between v3.4 and v3.5-rc1, the latter is a closer anchor point\n>> for that commit (v3.5-rc1 only needs about 200 hops to reach the\n>> commit, while from v3.4 you would need close to 500 hops),\n>\n> Ah! Thanks for explaining this mysterious puzzle to me. I'm a bit\n> perplexed why still. Can I trouble you for a little elaboration here?\n> How could one view from a commit merged on v3.4 possibly yield more\n> commits to v3.4 than to v3.5 ? Is it because it starts counting on the\n> merge's parent (v3.3) ?\n\nThe reason is very simple, once you realize that in a distributed\nenvironment it is very common to fork off a new branch from an\nancient commit and then merging the result to a newer release\nwithout merging it all the way down to older maintenance releases.\n\nTry this sequence:\n\n    1. start from say v3.4~1^2~2\n    $ git checkout -b side v3.4~1^2~2\n\nThe history near v3.4 proper looks like this:\n\n    $ git log --oneline -3 v3.4\n    76e10d1 Linux 3.4\n    d6c77973 Merge tag 'parisc-fixes' of git://git.kernel.o...\n    5d12045 Merge branch 'x86/ld-fix' of git://git.kernel.o...\n\nand the last merge before v3.4 brings three commits in to the\nhistory:\n\n    $ git log --oneline d6c77973^1..d6c77973^2\n    b3cb867 [PARISC] fix panic on prefetch(NULL) on PA7300LC\n    207f583 [PARISC] fix crash in flush_icache_page_asm on PA1.1\n    5e18558 [PARISC] fix PA1.1 oops on boot\n\nWe just forked a new \"side\" branch off of the bottom one (5e18558).\n\n    2. pretend a new development on this old codebase\n    $ git commit --allow-empty -m \"[PARISC] another\"\n\n    3. let's merge this to v3.5 and call the result v9.0\n    $ git checkout v3.5\n    $ git merge --no-edit side\n    $ git tag -a -m 'Nine' v9.0\n\nThink what just happened to v3.4~1^2~2, the fork-point of this new\nside branch (I am not asking what *should* happen. This exercise is\nonly to illustrate how the commit v3.5-rc1~120^3~76^2 can be closer\nto v3.5-rc1 than to v3.4 when it is reachable from both).\n\nHere is how the topology looks like:\n\n                   v3.4                  v9.0\n             ---M---X---------------------Y\n               /                         /\n   ---A---B---C                         /\n       \\                               / \n        ------------------------------D (side)\n\nwhere X is v3.4, M is d6c77973, A thru C are the PARISC patches,\nD is the \"another\", and Y is the phoney version Nine we just made.\nWe are trying to \"describe --contains\" commit A.\n\nIf you start counting from the new tag v9.0, it is on the merged\nside branch that brought in one new commit D, and in fact it is the\ndirect parent of it, so even without asking \"describe --contains\",\nwe know that it is v9.0^2~1.  That is 2 hops from v9.0 tag.  If you\ncount from v3.4, it is 4 hops.\n\nAnd both of these tags X and Y contain the commit A.\n\nNow, as to what *SHOULD* happen, I think the above exercise shows us\na way to define what the desired semantics is, without resorting to\nheuristics (e.g. \"which tag has older timestamp?\" or \"which tag's\nname sorts older under Linux version naming convention?\").\n\nCommit A can be described in terms of both v3.4 and v9.0, and it may\nbe closer to v9.0 than v3.4, and under that definition \"we pick the\nclosest tag\", the current \"describe --contains\" behaviour may be\ncorrect, but from the human point of view, it is *WRONG*.\n\nIt is wrong because v9.0 can reach v3.4.  So perhaps the rule should\nbe updated to do something like:\n\n    - find candidate tags that can be used to \"describe --contains\"\n      the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n\n    - among the candidate tags, cull the ones that contain another\n      candidate tag, rejecting v3.5 (not shown) and v9.0;\n\n    - among the surviving tags, pick the closest.\n\nHmm?\n"},{"id":"239022","messageId":"xmqq8ur3ga2y.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"mvm8ur42zn6.fsf@hawking.suse.de","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-17T17:05:57Z","receivedAt":"2014-04-17T17:05:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab <schwab@suse.de> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> And you are right that the commit is contained in v3.4, so we also\n>> should be able to describe it as v3.4~479^2~9^2 as well.\n>\n> IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git\n> describe --contains --match=v3.4\\* returns.  This path is only a few\n> commits longer than v3.5-rc1~120^3~76^2.\n\nSure. In my response to Luis, I assumed that rc tags are not as\ndesirable as the final release points for his purpose for whatever\nreason, as Luis compared between v3.4 and v3.5-rc1~120^3~76^2, not\nwith v3.4-rc1 or any later rc.\n\nI also think this illustrates my earlier point. Depending on the\nproject and the expectation of the users, which tags are good\ncandidates as anchor points differ.  Your example using --match\nprobably shows a good direction to go in---somehow tell Git which\ntags to base the description on, to reject names that the users do\nnot want.\n\nWhen your project does not mind basing the description on rc tags,\nbetween v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if\nwe would want to say that \"the former is not so longer than the\nlatter, so use that\", or what kind of heuristics to employ to reach\nthat conclusion.  Date-based selection (i.e. earliest first) is one\npossibility.  Tagname-based selection has the issue of having to\nconfigure \"whose version numbering convention would you use when\nsorting tags, and how you would tell Git that sorting order rule?\"\n\nFor a possible cleaner alternative semantics, see the other message\nI just sent to the thread.\n\nThanks.\n"},{"id":"239024","messageId":"87zjjj50eq.fsf@igel.home","threadId":"36427","inReplyTo":"xmqq8ur3ga2y.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Andreas Schwab","fromEmail":"schwab@suse.de","sentAt":"2014-04-17T17:30:21Z","receivedAt":"2014-04-17T17:30:21Z","isPatch":true,"sender":{"key":"schwab@suse.de","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I also think this illustrates my earlier point. Depending on the\n> project and the expectation of the users, which tags are good\n> candidates as anchor points differ.  Your example using --match\n> probably shows a good direction to go in---somehow tell Git which\n> tags to base the description on, to reject names that the users do\n> not want.\n\nI've used --match only to force git describe to find a better match.\n\n> When your project does not mind basing the description on rc tags,\n> between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if\n> we would want to say that \"the former is not so longer than the\n> latter, so use that\", or what kind of heuristics to employ to reach\n> that conclusion.  Date-based selection (i.e. earliest first) is one\n> possibility.  Tagname-based selection has the issue of having to\n> configure \"whose version numbering convention would you use when\n> sorting tags, and how you would tell Git that sorting order rule?\"\n\nIMHO git should select based on topology: the first tag that isn't\ncontained in any other tag still containing the commit in question, only\nwhen ambigous it needs to fall back to other criteria.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"239032","messageId":"xmqq7g6neqq2.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"87zjjj50eq.fsf@igel.home","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-17T18:49:25Z","receivedAt":"2014-04-17T18:49:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab <schwab@suse.de> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> ...\n>> When your project does not mind basing the description on rc tags,\n>> between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if\n>> we would want to say that \"the former is not so longer than the\n>> latter, so use that\", or what kind of heuristics to employ to reach\n>> that conclusion.  Date-based selection (i.e. earliest first) is one\n>> possibility.  Tagname-based selection has the issue of having to\n>> configure \"whose version numbering convention would you use when\n>> sorting tags, and how you would tell Git that sorting order rule?\"\n>\n> IMHO git should select based on topology: the first tag that isn't\n> contained in any other tag still containing the commit in question, only\n> when ambigous it needs to fall back to other criteria.\n\nI think we are in agreement.  In the part you chopped from your\nquote, I said:\n\n>> For a possible cleaner alternative semantics, see the other message\n>> I just sent to the thread.\n\ndidn't I?\n"},{"id":"239056","messageId":"20140417221619.GA697@sigill.intra.peff.net","threadId":"36427","inReplyTo":"xmqqfvlbga4r.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-17T22:16:20Z","receivedAt":"2014-04-17T22:16:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 17, 2014 at 10:04:52AM -0700, Junio C Hamano wrote:\n\n> Commit A can be described in terms of both v3.4 and v9.0, and it may\n> be closer to v9.0 than v3.4, and under that definition \"we pick the\n> closest tag\", the current \"describe --contains\" behaviour may be\n> correct, but from the human point of view, it is *WRONG*.\n> \n> It is wrong because v9.0 can reach v3.4.  So perhaps the rule should\n> be updated to do something like:\n> \n>     - find candidate tags that can be used to \"describe --contains\"\n>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n> \n>     - among the candidate tags, cull the ones that contain another\n>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n> \n>     - among the surviving tags, pick the closest.\n> \n> Hmm?\n\nInteresting.  I think that would cover some cases, but there are others\nin which the tags are not direct descendants. For example, imagine you\nhave both a \"master\" and a \"maint\" branch. You fork a topic from an old\ncommit that both branches contain, and then independently merge the\ntopic to each branch. You then cut a release for each. So your graph\nmight look like:\n\n ---A---B---C-----D---E---F (maint, v3.4)\n     \\   \\       /\n      \\   ---G-----H---I (master, v4.0)\n       \\       /  /\n        ------J---\n\nThe fix is J, and it got merged up to maint at D, and to master at H.\nv4.0 does not contain v3.4. What's the best description of J?\n\nBy the rules above, we hit the third rule \"pick the closest\". Which\nmeans we choose v3.4 or v4.0 based solely on how many commits are\nbetween the topic's merge and the tag release. Which has nothing at all\nto do with the topic itself.\n\nIn this case we'd show v4.0 (because \"J-H-I\" is shorter than \"J-D-E-F\").\nBut I suspect most users would want to know v3.4, because they want to\nknow the \"oldest\" release they can move up to that contains the commit.\nBut that notion of oldness is not conveyed by the graph above; it's only\nan artifact of the tag names.\n\nSo you can solve this by actually representing the relationship with a\nmerge. IOW, by merging v3.4 into v4.0 to say \"yes, v4.0 is a superset\".\nAnd that's generally what we do in git.git, merging maint into master\nperiodically. But I imagine there are other possible workflows where\npeople do not do that \"merge up\", and the maint and master branches\ndiverge (and maybe they even cherry-pick from each other, but sometimes\nmerge if the fix can be based on a common ancestor, as in this case).\n\n-Peff\n"},{"id":"239071","messageId":"xmqqlhv2d2no.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"20140417221619.GA697@sigill.intra.peff.net","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-18T16:26:51Z","receivedAt":"2014-04-18T16:26:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>  ---A---B---C-----D---E---F (maint, v3.4)\n>      \\   \\       /\n>       \\   ---G-----H---I (master, v4.0)\n>        \\       /  /\n>         ------J---\n>\n> The fix is J, and it got merged up to maint at D, and to master at H.\n> v4.0 does not contain v3.4. What's the best description of J?\n>\n> By the rules above, we hit the third rule \"pick the closest\". Which\n> means we choose v3.4 or v4.0 based solely on how many commits are\n> between the topic's merge and the tag release. Which has nothing at all\n> to do with the topic itself.\n\nEven if J..F and J..I were of the same hop-count, there is no\nfundamental reason to choose one over the other.\n\nWhat is \"best\" at that point depends on what the user wants to see.\n\n - Luis's case that started this thread may want to favor v3.4 if\n   only because that \"sounds\" the smaller, even though v3.4 and v4.0\n   in the illustration cannot be compared.\n\n - I think the \"closest\" we have had is primarily a heuristic to\n   favour the result that is textually shorter.\n\n - And as I alluded to, \"which one has the earliest timestamp?\", is\n   another valid question to ask.\n\nIn other words, there is no single \"correct\" answer, once you have\nmultiple canidates that are all valid from topological point of\nview.\n\n> In this case we'd show v4.0 (because \"J-H-I\" is shorter than \"J-D-E-F\").\n> But I suspect most users would want to know v3.4, because they want to\n> know the \"oldest\" release they can move up to that contains the commit.\n> But that notion of oldness is not conveyed by the graph above; it's only\n> an artifact of the tag names.\n\nYes, exactly.\n"},{"id":"239084","messageId":"CAB=NE6Vt8etieyR256Hxb=q6zMo7UAO2Zkm5900NrE+4=-3eXA@mail.gmail.com","threadId":"36427","inReplyTo":"xmqqfvlbga4r.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Luis R. Rodriguez","fromEmail":"mcgrof@do-not-panic.com","sentAt":"2014-04-18T23:17:38Z","receivedAt":"2014-04-18T23:17:38Z","isPatch":true,"sender":{"key":"mcgrof@do-not-panic.com","avatar":null},"body":"On Thu, Apr 17, 2014 at 10:04 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n>\n>>> And between v3.4 and v3.5-rc1, the latter is a closer anchor point\n>>> for that commit (v3.5-rc1 only needs about 200 hops to reach the\n>>> commit, while from v3.4 you would need close to 500 hops),\n>>\n>> Ah! Thanks for explaining this mysterious puzzle to me. I'm a bit\n>> perplexed why still. Can I trouble you for a little elaboration here?\n\n< Junio gives a great huge example>\n\nPhew! Thanks for the elaborate explanation, this makes perfect sense now!\n\n> Now, as to what *SHOULD* happen, I think the above exercise shows us\n> a way to define what the desired semantics is, without resorting to\n> heuristics (e.g. \"which tag has older timestamp?\" or \"which tag's\n> name sorts older under Linux version naming convention?\").\n\nI think ultimately this reveals that given that tags *can* be\narbitrary and subjective, and given that clocks can also pretty much\narbitrary 'git describe --contains' can and probably only should do\nbest effort (TM) and perhaps one thing to help is documenting this\nissue well and provide a set of best practices that are supported for\ntagging schemes. I can't describe how many libraries I've reviewed\nabout software versioning schemes and most of them support a huge\narray of things, and funny enough the Linux versioning scheme, was not\nsupported well, for something so simple as versioning sort. This is\nultimately why I had to implement my own sort solution on rel-html. If\nwe agree on this we could just for example take on the Linux\nversioning scheme as an emum and document that well both on code and a\nwiki. More on this below.\n\nWith regards to timestamps: care must be taken given that we'd be\nassuming that clocks are synchronized, this can likely yield incorrect\nresults on a distributed development environment with different time\nzones, and it can also be easily cheated, which is why I was concerned\nover using timestamps. Its still certainly something that can be\nconsidered, but I've heard enough rants of a few maintainers about\ncrazy dates on patches which makes me believe this could actually be\nan issue, specially if we speed up development and need higher degree\nof resolution.\n\nI know the above example but its perhaps worth mentioning how Linux\ndoes not follow the above development model for merging stable fixes\nor changes though, but it does not prevent folks from branching off of\nolder tags to do development which Linux will then pull. In Ingo's\ncase the issue then points then I think to another mild issue -- the\ncommit was developed on a v3.3 based tag, which is why 'git describe\n--first-parent c5905afb' yields v3.3-rc1-41-gc5905af and not v3.4,\nwhich *can also* be a bit perplexing if one does not understand the\nabove example you provided can be used for a development work flow for\ncode sent out to Linus. That said then, since we don't follow the\nmodel you laid out it still reveals another issue, and I am not yet\nsure I still understand why --contains yields a v3.5 tag in that case\nsince we ensured commits on v3.5 were already piled up on older\nreleases, or were being introduced newly on its own release. It smells\nto me that the commit's first parent (which can be anything) is used\nsomehow here as a shortcut ?\n\nThis doesn't mean we can't use the work flow above for merging changes\nfrom say a v3.4.x onto a v3.5 -- but we don't -- and perhaps as part\nof the documentation about a scheme for Linux, we should advise\nagainst such practices. In any case the closest thing I see we can use\nupstream on Linux is 'git cherry-pick -x <commit-id>' but Greg doesn't\nseem to use this and instead appends the commit with the respective\ncommit ID of the upstream gitsum. Both strategies yield different\ncommit IDs anyway, so neither practice should interrupt the 'git\ndescribe --contains' practice. In the stable branches to find out when\na commit was introduced one would not rely on the commit ID on the\nstable branch but instead of the commit ID of the 'upstream\nreference'.\n\n> Commit A can be described in terms of both v3.4 and v9.0,\n\nAnd in the real example case, why *would* c5905afb' be be described in\nterms of v3.5 instead of v3.4 ?\n\n> and it may\n> be closer to v9.0 than v3.4, and under that definition \"we pick the\n> closest tag\", the current \"describe --contains\" behaviour may be\n> correct, but from the human point of view, it is *WRONG*.\n\nYeap, if a development work flow does not follow a strict pattern\n(maybe a .git/config variable?) perhaps 'git describe --contains'\nshould spit out a the few tags it does have?\n\n> It is wrong because v9.0 can reach v3.4.  So perhaps the rule should\n> be updated to do something like:\n>\n>     - find candidate tags that can be used to \"describe --contains\"\n>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n\nSure.\n\n>\n>     - among the candidate tags, cull the ones that contain another\n>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n\nSounds good to me but that seems to stick the output to a scheme, ie,\nwould it support schemes without a v prefix for tags? In other words,\nperhaps do this only for Linux scheme?\n\n>     - among the surviving tags, pick the closest.\n>\n> Hmm?\n\nSounds good to me!\n\n  Luis\n"},{"id":"239085","messageId":"xmqq7g6mb47f.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"CAB=NE6Vt8etieyR256Hxb=q6zMo7UAO2Zkm5900NrE+4=-3eXA@mail.gmail.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-18T23:36:20Z","receivedAt":"2014-04-18T23:36:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n\n> I think ultimately this reveals that given that tags *can* be\n> arbitrary and subjective,...\n\nYes; see the part at the bottom.\n\n>> Commit A can be described in terms of both v3.4 and v9.0,\n>\n> And in the real example case, why *would* c5905afb' be be described in\n> terms of v3.5 instead of v3.4 ?\n\nI am not interested in graphing that particular history between v3.4\nand v3.5 myself.  If you are interested, I already gave you enough\ninformation on how to figure that out.\n\n>>     - find candidate tags that can be used to \"describe --contains\"\n>>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n>\n>>     - among the candidate tags, cull the ones that contain another\n>>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n>\n>>     - among the surviving tags, pick the closest.\n>>\n>> Hmm?\n>\n> Sounds good to me!\n\nNot so fast ;-)\n\nMy other message to Peff in response to his another example has an\nupdated position on this.  \"Reject candidates that can reach other\ncandidates\" is universally correct, but after that point, there are\nat least three but probably more options that suit preference of\ndifferent people and project to break ties:\n\n - Your case that started this thread may want to favor v3.4 if only\n   because that v3.4 _sounds_ smaller than v4.0 (in Peff's example),\n   even when v3.4 and v4.0 do not have ancestry relationship.\n\n - The \"closest\" we have had is a heuristic to produce a result that\n   is textually shorter.\n\n - And as I alluded to, \"which one has the earliest timestamp?\", is\n   another valid question to ask.\n\nAnd there may be more to appear.  A new command line option (and\npossibly a new configuration) to choose from these three (and more\nheuristics that will be added later) would be necessary.\n"},{"id":"239278","messageId":"CAB=NE6U7zYurAXNvjkHmk12Qsp9rerr=JyMjrVHrab98h9_+gQ@mail.gmail.com","threadId":"36427","inReplyTo":"xmqq7g6mb47f.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Luis R. Rodriguez","fromEmail":"mcgrof@do-not-panic.com","sentAt":"2014-04-22T00:38:34Z","receivedAt":"2014-04-22T00:38:34Z","isPatch":true,"sender":{"key":"mcgrof@do-not-panic.com","avatar":null},"body":"On Fri, Apr 18, 2014 at 4:36 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Luis R. Rodriguez\" <mcgrof@do-not-panic.com> writes:\n>\n>> I think ultimately this reveals that given that tags *can* be\n>> arbitrary and subjective,...\n>\n> Yes; see the part at the bottom.\n>\n>>> Commit A can be described in terms of both v3.4 and v9.0,\n>>\n>> And in the real example case, why *would* c5905afb' be be described in\n>> terms of v3.5 instead of v3.4 ?\n>\n> I am not interested in graphing that particular history between v3.4\n> and v3.5 myself.  If you are interested, I already gave you enough\n> information on how to figure that out.\n\nI was alluding to another possible issue here, my concern was that the\ncommit's parent (which is not really the point at which it was merged,\nbut rather where the topic got forked off to be worked on) could be\nused for as reference points but clearly its not given the nature of\nhow name-rev was implemented. I still do see some possible issues with\nit's parent on other commands (but I haven't studied the other's\nimplementation) that reveals some of my original concerns, but its\nunclear if they are related. I also found that if we didn't want to\nrely on dates or start defining naming convention we may want to\nreconsider the name_rev() recursive implementation. I'll illustrate a\nfew results that might help to show my concerns for both other\ncommands perhaps using the parent erroneously, and a possible\nalternative implementation for name_rev() or at the very least\ncontains.\n\n[0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep\n^commit | wc -l\n24878\n[1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep\n^commit | wc -l\n13106\n[2] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.3| grep\n^commit | wc -l\n1360\n\nNow that I revised name_rev.c I see the recursive nature of name_rev()\nworks top down from each tag down to each v* tag object and for each\nactual commit pegs a name on it. How we rule out each tag under this\nimplementation is not that obvious to me, specially when results like\n[0] and [1] reveal v3.4 should be 'shorter' in light of number of\ncommits. I see now how we don't update a commit's name if other\ncrucial information such as the ones discussed on this thread might be\nimportant for the user, and I can see how this can help but an\nalternative approach, which is what I expected to see implemented at\nleast for 'git describe --contains', would have been to see how many\ncommits are present from the commit's *merged* upstream parent (not\nthe actual parent as in c5905afb's commit case its v3.3 which is not\nwhere it got merged). Getting the smallest number of commits under\nthis logic and stopping when we don't find any commits should yield us\nthe base tag under which the commit was merged, without any heuristics\non dates. This however applies to Linux though given that we don't\nmerge commits on stable branches but rather create new commits and\nreference the upstream sha1sum, a practice which also solves the\nproblem Jeff pointed out.\n\nThe results for command [2] above however a bit surprising, I'd take a\nlook but I should go back to look at other stuff, figured I'd at least\nbring it up now as it seems relevant.\n\n>>>     - find candidate tags that can be used to \"describe --contains\"\n>>>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n>>\n>>>     - among the candidate tags, cull the ones that contain another\n>>>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n>>\n>>>     - among the surviving tags, pick the closest.\n>>>\n>>> Hmm?\n>>\n>> Sounds good to me!\n>\n> Not so fast ;-)\n>\n> My other message to Peff in response to his another example has an\n> updated position on this.  \"Reject candidates that can reach other\n> candidates\" is universally correct, but after that point, there are\n> at least three but probably more options that suit preference of\n> different people and project to break ties:\n>\n>  - Your case that started this thread may want to favor v3.4 if only\n>    because that v3.4 _sounds_ smaller than v4.0 (in Peff's example),\n>    even when v3.4 and v4.0 do not have ancestry relationship.\n>\n>  - The \"closest\" we have had is a heuristic to produce a result that\n>    is textually shorter.\n>\n>  - And as I alluded to, \"which one has the earliest timestamp?\", is\n>    another valid question to ask.\n\nThe first one above can be subjective if and only if the Linux\nupstream model of dealing with stable branches is not followed. In\nother words I think its a non issue if you create new commits on the\nstable branches instead of merge stuff onto them. This however is\ntechnical practice and I guess not everyone follows.\n\n> And there may be more to appear.  A new command line option (and\n> possibly a new configuration) to choose from these three (and more\n> heuristics that will be added later) would be necessary.\n\nYeah this is rather complex, the resolutions to the issue in the ways\nyou've described seem reasonable to me but do wonder if this can be\nsimplified by reevaluating how the candidates are considered. You'd\nknow better :)\n\n Luis\n"},{"id":"239286","messageId":"20140422040443.GC9243@odin.tremily.us","threadId":"36427","inReplyTo":"CAB=NE6U7zYurAXNvjkHmk12Qsp9rerr=JyMjrVHrab98h9_+gQ@mail.gmail.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-04-22T04:04:43Z","receivedAt":"2014-04-22T04:04:43Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Apr 21, 2014 at 05:38:34PM -0700, Luis R. Rodriguez wrote:\n> [0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep\n> ^commit | wc -l\n> 24878\n> [1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep\n> ^commit | wc -l\n> 13106\n> [2] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.3| grep\n> ^commit | wc -l\n> 1360\n\nFrom gitrevisions(7), r1..r2 is “commits that are reachable from r2\nexcluding those that are reachable from r1”.  Using Peff's example:\n\nOn Thu, Apr 17, 2014 at 06:16:20PM -0400, Jeff King wrote:\n>  ---A---B---C-----D---E---F (maint, v3.4)\n>      \\   \\       /\n>       \\   ---G-----H---I (master, v4.0)\n>        \\       /  /\n>         ------J---\n> \n> The fix is J, and it got merged up to maint at D, and to master at H.\n> v4.0 does not contain v3.4. What's the best description of J?\n\nJ..v3.4 is going to include B, C, D, E and F.  However, the “distance”\nused by ‘git describe’ uses the shortest path between the commits\n(J-D-E-F), which doesn't care about development between A and D.\n\n> The results for command [2] above however a bit surprising, I'd take a\n> look but I should go back to look at other stuff, figured I'd at least\n> bring it up now as it seems relevant.\n\nHere's a simplified graph with d1-* tags for the v3.5-rc1~120^3~76^2\ndescription and d2-* tags for the v3.4~479^2~9^2 description [1]:\n\n  * f8f5701 (tag: v3.5-rc1) Linux 3.5-rc1\n  * 912afc3 (tag: d1-F) Merge tag 'dm-3.5-changes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm\n  *   56edab3 (tag: d1-E) Merge branches 'perf-urgent-for-linus' and 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip\n  |\\  \n  | * ab0cce5 (tag: d1-D) Revert \"sched, perf: Use a single callback into the scheduler\"\n  | * 26252ea (tag: d1-C-1, tag: d1-C) perf evlist: Show event attribute details\n  | *   a385ec4 (tag: d1-C-64) Merge tag 'v3.4-rc2' into perf/core\n  | |\\\n  | * \\ 659c36f (tag: d1-C-65) Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core\n  | |\\ \\\n  | | * | 5a7ed29 (tag: d1-C-65-2) perf record: Use sw counter only if hw pmu is not detected\n  * | |/  76e10d1 (tag: v3.4) Linux 3.4\n  | |/|  \n  |/| |  \n  * |/ dd775ae (tag: v3.4-rc1) Linux 3.4-rc1\n  |/|  \n  * |  c5bc437 Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent\n  |\\|  \n  | * 9521d83 (tag: d1-C-66) Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core\n  * |   9c2b957 (tag: d2-E) Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip\n  |\\ \\  \n  | |/  \n  | * bea95c1 (tag: d2-D, tag: d1-C-67) Merge branch 'perf/hw-branch-sampling' into perf/core\n  | * f9b4eeb (tag: d2-C, tag: d1-C-68) perf/x86: Prettify pmu config literals\n  | * a706d4f (tag: d2-B, tag: d1-C-76, tag: d1-B) Merge branch 'perf/jump-labels' into perf/core\n  | * c5905af (tag: A) static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()\n  * | c16fa4f (tag: v3.3) Linux 3.3\n  |/  \n  * dcd6c92 (tag: v3.3-rc1) Linux 3.3-rc1\n\nThis shows the v3.4-rc1 bypass from 9521d83 (d1-C-66) to 659c36f\n(d1-C-65) which sets up the v3.5-rc1~120^3~76 description.  It also\nshows the c5905afb..v3.3 commits on the branch from c5905af's fork\n(between v3.3-rc1 and v3.3) and v3.3.\n\nCheers,\nTrevor\n\n[1]: The simplified graph is from:\n\n  $ git tag A c5905afb\n  $ git tag d1-B v3.5-rc1~120^3~76\n  $ git tag d1-C v3.5-rc1~120^3~1\n  $ git tag d1-D v3.5-rc1~120^3\n  $ git tag d1-E v3.5-rc1~120\n  $ git tag d1-F v3.5-rc1~1\n  $ for x in $(seq 76); do git tag d1-C-$x v3.5-rc1~120^3~$x; done\n  $ git tag d1-C-65-2 d1-C-65^2\n  $ git tag d2-B v3.4~479^2~9\n  $ git tag d2-C v3.4~479^2~1\n  $ git tag d2-D v3.4~479^2\n  $ git tag d2-E v3.4~479\n  $ git tag -d sound-fixes sound-3.4 v3.3-rc{2,3,4,5,6,7} v3.4-rc{2,3,4,5,6,7}\n  $ git log --graph --topo-order --oneline --decorate --simplify-by-decoration v3.5-rc1\n  …simplified graph…\n  $ git tag -d A d1-{B,C,D,E,F} d2-{B,C,D,E} d1-C-65-2 \n  $ for x in $(seq 76); do git tag -d d1-C-$x; done\n\nWith some additional tweaks to cull the d1-C-* bits we don't care\nabout and clear up the 659c36f (d1-C-65) merge.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"239324","messageId":"20140422102713.GC366@quack.suse.cz","threadId":"36427","inReplyTo":"xmqqfvlbga4r.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Jan Kara","fromEmail":"jack@suse.cz","sentAt":"2014-04-22T10:27:13Z","receivedAt":"2014-04-22T10:27:13Z","isPatch":true,"sender":{"key":"jack@suse.cz","avatar":null},"body":"On Thu 17-04-14 10:04:52, Junio C Hamano wrote:\n> So perhaps the rule should be updated to do something like:\n> \n>     - find candidate tags that can be used to \"describe --contains\"\n>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n> \n>     - among the candidate tags, cull the ones that contain another\n>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n>\n>     - among the surviving tags, pick the closest.\n  I guess all parties agree with the first two points (and actually I would\nprefer not to assume anything about tag names and consider v3.4-rc1 as good\nas v3.4). Regarding the strategy what to select when there are several\nremaining tags after first two steps I would prefer to output all such\ntags. As people have mentioned in this thread it varies a lot between\nprojects what people want to see (and in some cases I can imagine people\nreally *want* to see all the tags). So printing all such tags would let\nthem select the desired tag with grep or some more elaborate scripting...\nJust a thought.\n\n\t\t\t\t\t\t\t\tHonza\n-- \nJan Kara <jack@suse.cz>\nSUSE Labs, CR\n"},{"id":"239357","messageId":"xmqqppk95jrj.fsf@gitster.dls.corp.google.com","threadId":"36427","inReplyTo":"20140422102713.GC366@quack.suse.cz","subject":"Re: [PATCH] tag: add -i and --introduced modifier for --contains","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-22T17:58:08Z","receivedAt":"2014-04-22T17:58:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Kara <jack@suse.cz> writes:\n\n> On Thu 17-04-14 10:04:52, Junio C Hamano wrote:\n>> So perhaps the rule should be updated to do something like:\n>> \n>>     - find candidate tags that can be used to \"describe --contains\"\n>>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;\n>> \n>>     - among the candidate tags, cull the ones that contain another\n>>       candidate tag, rejecting v3.5 (not shown) and v9.0;\n>>\n>>     - among the surviving tags, pick the closest.\n> ...\n> Regarding the strategy what to select when there are several\n> remaining tags after first two steps I would prefer to output all such\n> tags.\n\nYes, as I mentioned in another subthread ($gmane/246488), different\nprojects want different tie-breaking rules at the third step, and\nyour \"show all to give more information to the user\" could be\nanother mode of operation.\n\nI offhand do not think the current name-rev machinery is set up to\ncompute your variant easily, though.\n"}]}