{"thread":{"id":"55511","subject":"[BUG?] 'git describe seen'?","startedAt":"2021-04-17T23:46:07Z","lastAt":"2021-04-18T13:27:11Z","messageCount":5,"participants":["Junio C Hamano","SZEDER Gábor","René Scharfe","Bagas Sanjaya"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422196","messageId":"xmqq1rb8bhl4.fsf@gitster.g","threadId":"55511","inReplyTo":null,"subject":"[BUG?] 'git describe seen'?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-17T23:45:59Z","receivedAt":"2021-04-17T23:46:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This does not seem a new problem at all, as v2.10.0 thru more recent\nversions of \"git describe\" seem to give me the same answer.\n\nAnyway, I am seeing a curious symptom.\n\n$ git rev-list --count v2.31.0..seen\n716\n$ git rev-list --count v2.31.1..seen\n687\n\nThe above means that 'seen' is closer to v2.31.1 than v2.31.0; there\nare fewer commits that are not in v2.31.1 that are in 'seen', than\ncommits that are not in v2.31.0 that are in 'seen'.  \n\nThat is naturally expected.\n\n$ git rev-list --count v2.31.0..v2.31.1\n29\n\nAnd that difference of 29 matches the difference, which is 716 - 687.\n\nBut here is what is puzzling.\n\n$ git describe seen\nv2.31.0-716-g7b65b53281\n\n$ git rev-list --first-parent master..seen |\n  while read v\n  do\n\td=$(git describe $v)\n\techo $v $d\n\tcase \"$d\" in v2.31.1-*) break ;; esac\n  done\n7b65b53281ae06ee25dd47dead4062125eb54427 v2.31.0-716-g7b65b53281\neec14f0fec886c909a29d63a94537df5a62be618 v2.31.0-714-geec14f0fec\n...\n103835562c64abef2319995716230f92092f87af v2.31.0-569-g103835562c\nd4324831d9152b16e091646e22a6e03423a59c93 v2.31.1-516-gd4324831d9\n\nIs there something tricky about the topic merged at 10383556 (Merge\nbranch 'jh/rfc-builtin-fsmonitor' into seen, 2021-04-17) to confuse\nthe counting done in \"git describe\"?\n\n$ git log --first-parent --oneline master..103835562^2\n14d50074ff t7527: test status with untracked-cache and fsmonitor--daemon\n07dbff70ce p7519: add fsmonitor--daemon\n436807f77a t7527: create test for fsmonitor--daemon\nc826602412 fsmonitor: force update index when fsmonitor token advances\naaaf17ce60 fsmonitor--daemon: use a cookie file to sync with file system\n71a0e07d79 fsmonitor--daemon:: introduce client delay for testing\n9aedb0f1ea fsmonitor--daemon: periodically truncate list of modified files\nd4ae16b416 fsmonitor--daemon: implement handle_client callback\n94f826fd48 fsmonitor-fs-listen-macos: implement FSEvent listener on MacOS\n25663103ea fsmonitor-fs-listen-macos: add macos header files for FSEvent\ne504205db7 fsmonitor-fs-listen-win32: implement FSMonitor backend on Windows\n5e207d2af6 fsmonitor--daemon: create token-based changed path cache\n42f493472f fsmonitor--daemon: define token-ids\n082b8085d3 fsmonitor--daemon: add pathname classification\nd4f4c59e56 fsmonitor--daemon: implement daemon command options\naec39650b5 fsmonitor-fs-listen-macos: stub in backend for MacOS\n100cb9e8ad fsmonitor-fs-listen-win32: stub in backend for Windows\n404d7dbdb6 fsmonitor--daemon: implement client command options\n1f2d717bd6 fsmonitor--daemon: add a built-in fsmonitor daemon\n4b10913cfe fsmonitor: introduce `core.useBuiltinFSMonitor` to call the daemon via IPC\n867611645c config: FSMonitor is repository-specific\n6e74370ce4 fsmonitor-ipc: create client routines for git-fsmonitor--daemon\nff338b5790 Merge branch 'jh/simple-ipc' into jh/rfc-builtin-fsmonitor\n"},{"id":"422203","messageId":"20210418082104.GT2947267@szeder.dev","threadId":"55511","inReplyTo":"xmqq1rb8bhl4.fsf@gitster.g","subject":"Re: [BUG?] 'git describe seen'?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2021-04-18T08:21:04Z","receivedAt":"2021-04-18T08:21:10Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Apr 17, 2021 at 04:45:59PM -0700, Junio C Hamano wrote:\n> This does not seem a new problem at all, as v2.10.0 thru more recent\n> versions of \"git describe\" seem to give me the same answer.\n> \n> Anyway, I am seeing a curious symptom.\n> \n> $ git rev-list --count v2.31.0..seen\n> 716\n> $ git rev-list --count v2.31.1..seen\n> 687\n> \n> The above means that 'seen' is closer to v2.31.1 than v2.31.0; there\n> are fewer commits that are not in v2.31.1 that are in 'seen', than\n> commits that are not in v2.31.0 that are in 'seen'.  \n> \n> That is naturally expected.\n> \n> $ git rev-list --count v2.31.0..v2.31.1\n> 29\n> \n> And that difference of 29 matches the difference, which is 716 - 687.\n> \n> But here is what is puzzling.\n> \n> $ git describe seen\n> v2.31.0-716-g7b65b53281\n> \n> $ git rev-list --first-parent master..seen |\n>   while read v\n>   do\n> \td=$(git describe $v)\n> \techo $v $d\n> \tcase \"$d\" in v2.31.1-*) break ;; esac\n>   done\n> 7b65b53281ae06ee25dd47dead4062125eb54427 v2.31.0-716-g7b65b53281\n> eec14f0fec886c909a29d63a94537df5a62be618 v2.31.0-714-geec14f0fec\n> ...\n> 103835562c64abef2319995716230f92092f87af v2.31.0-569-g103835562c\n> d4324831d9152b16e091646e22a6e03423a59c93 v2.31.1-516-gd4324831d9\n> \n> Is there something tricky about the topic merged at 10383556 (Merge\n> branch 'jh/rfc-builtin-fsmonitor' into seen, 2021-04-17) to confuse\n> the counting done in \"git describe\"?\n\nSubsequent merges with identical timestamps can easily confuse 'git\ndescribe', I wonder whether this is another symptom of the issue\nreported at:\n\n  https://public-inbox.org/git/20191008123156.GG11529@szeder.dev/\n\n"},{"id":"422207","messageId":"20210418094347.GU2947267@szeder.dev","threadId":"55511","inReplyTo":"20210418082104.GT2947267@szeder.dev","subject":"Re: [BUG?] 'git describe seen'?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2021-04-18T09:43:47Z","receivedAt":"2021-04-18T09:43:52Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Apr 18, 2021 at 10:21:04AM +0200, SZEDER Gábor wrote:\n> On Sat, Apr 17, 2021 at 04:45:59PM -0700, Junio C Hamano wrote:\n> > This does not seem a new problem at all, as v2.10.0 thru more recent\n> > versions of \"git describe\" seem to give me the same answer.\n> > \n> > Anyway, I am seeing a curious symptom.\n> > \n> > $ git rev-list --count v2.31.0..seen\n> > 716\n> > $ git rev-list --count v2.31.1..seen\n> > 687\n> > \n> > The above means that 'seen' is closer to v2.31.1 than v2.31.0; there\n> > are fewer commits that are not in v2.31.1 that are in 'seen', than\n> > commits that are not in v2.31.0 that are in 'seen'.  \n> > \n> > That is naturally expected.\n> > \n> > $ git rev-list --count v2.31.0..v2.31.1\n> > 29\n> > \n> > And that difference of 29 matches the difference, which is 716 - 687.\n> > \n> > But here is what is puzzling.\n> > \n> > $ git describe seen\n> > v2.31.0-716-g7b65b53281\n> > \n> > $ git rev-list --first-parent master..seen |\n> >   while read v\n> >   do\n> > \td=$(git describe $v)\n> > \techo $v $d\n> > \tcase \"$d\" in v2.31.1-*) break ;; esac\n> >   done\n> > 7b65b53281ae06ee25dd47dead4062125eb54427 v2.31.0-716-g7b65b53281\n> > eec14f0fec886c909a29d63a94537df5a62be618 v2.31.0-714-geec14f0fec\n> > ...\n> > 103835562c64abef2319995716230f92092f87af v2.31.0-569-g103835562c\n> > d4324831d9152b16e091646e22a6e03423a59c93 v2.31.1-516-gd4324831d9\n> > \n> > Is there something tricky about the topic merged at 10383556 (Merge\n> > branch 'jh/rfc-builtin-fsmonitor' into seen, 2021-04-17) to confuse\n> > the counting done in \"git describe\"?\n> \n> Subsequent merges with identical timestamps can easily confuse 'git\n> describe', I wonder whether this is another symptom of the issue\n> reported at:\n> \n>   https://public-inbox.org/git/20191008123156.GG11529@szeder.dev/\n\nThat is not the only issue playing a role here, though.\n\n'git describe --debug ...' shows a handful of candidate tags sorted\n(primarily) by their depth counted from the to-be-described commit:\n\n  $ git describe --debug origin/seen\n  describe origin/seen\n  No exact match on refs or tags, searching to describe\n   annotated        716 v2.31.0\n   annotated        708 v2.31.1\n   annotated        733 v2.31.0-rc2\n   annotated        755 v2.31.0-rc1\n   annotated        818 v2.31.0-rc0\n   annotated        895 v2.30.2\n   annotated        897 v2.29.3\n   annotated        899 v2.28.1\n   annotated        901 v2.27.1\n   annotated        903 v2.26.3\n  traversed 3768 commits\n  more than 10 tags found; listed 10 most recent\n  gave up search at 42ce4c7930ff494136256554cbed730857084c70\n  v2.31.0-716-g7b65b53281\n\nNotice two issues with this output:\n\n  - v2.31.0's depth is ok, but v2.31.1's is wrong:\n\n      $ git rev-list --count v2.31.0..origin/seen\n      716\n      $ git rev-list --count v2.31.1..origin/seen\n      687\n\n  - The order of v2.31.0 and v2.31.1 is clearly wrong.\n\n    I think this is because of the following code snippet from\n    builtin/describe.c:describe_commit():\n\n        QSORT(all_matches, match_cnt, compare_pt);\n\n        if (gave_up_on) {\n                commit_list_insert_by_date(gave_up_on, &list);\n                seen_commits--;\n        }\n        seen_commits += finish_depth_computation(&list, &all_matches[0]);\n        free_commit_list(list);\n\n    I.e. we sort based on depth before calling\n    finish_depth_computation(), which doesn't look right...  Looking\n    at the depths before sorting shows that v2.31.1's depth is the\n    same (708), but v2.31.0's depth is only 696 instead of 716.  Now,\n    while this explains why those two tags are listed in the wrong\n    order, it is still troubling that v2.31.0's depth is lower that\n    v2.31.1's.\n\n    Switching the order of finish_depth_computation() and QSORT() does\n    fix thier order based on their depth, but, alas, those depths are\n    still wrong:\n\n      $ ./bin-wrappers/git describe --debug origin/seen\n      describe origin/seen\n      No exact match on refs or tags, searching to describe\n       annotated        696 v2.31.0\n       annotated        729 v2.31.1\n       annotated        733 v2.31.0-rc2\n       annotated        755 v2.31.0-rc1\n       annotated        818 v2.31.0-rc0\n       annotated        895 v2.30.2\n       annotated        897 v2.29.3\n       annotated        899 v2.28.1\n       annotated        901 v2.27.1\n       annotated        903 v2.26.3\n      traversed 3768 commits\n      more than 10 tags found; listed 10 most recent\n      gave up search at 42ce4c7930ff494136256554cbed730857084c70\n      v2.31.0-696-g7b65b53281\n\n    However, switching the order of finish_depth_computation() and\n    QSORT() might be wrong in itself: finish_depth_computation() was\n    introduced in 1b600e659a (Compute accurate distances in\n    git-describe before output., 2007-01-27), which states [1] the\n    following in its commit message:\n\n      We can easily reduce the total number of commits that need to be\n      walked at the end by stopping as soon as all of the commits in the\n      commit queue are flagged as being merged into the already selected\n      best possible tag.\n\n    But which candidate is that \"best possible tag\"?  The one whose\n    depth is the lowest, so we do have to sort before calling\n    finish_depth_computation() (or, strictly speaking, we don't have\n    to sort, we only have to find the candidate with the lowest\n    depth).\n\nAt this point I call it quits, because I don't think we can't talk\nabout accurate depth at all without first fixing the issue I linked in\nmy previous message.\n\n\n[1] 1b600e659a also states the following:\n\n      This means we can simply finish\n      counting out the revisions still in our commit queue to present\n      the accurate distance at the end.  The number of commits remaining\n      in the commit queue is probably less than the number of commits\n      already traversed, so finishing out the count is not likely to take\n      very long. \n\n   Looking at the 'seen_commits' variable shows that in this\n   particular case we traverse 905 commits before calling\n   finish_depth_computation(), which then traverses an additional\n   3768 - 905 = 2863 commits, i.e. the assumption in 1b600e659a might\n   not hold.\n\n"},{"id":"422208","messageId":"5cb071aa-16d1-8ea8-39e7-a0f5b89cbf3a@web.de","threadId":"55511","inReplyTo":"xmqq1rb8bhl4.fsf@gitster.g","subject":"Re: [BUG?] 'git describe seen'?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-04-18T10:26:45Z","receivedAt":"2021-04-18T10:26:55Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 18.04.21 um 01:45 schrieb Junio C Hamano:\n> This does not seem a new problem at all, as v2.10.0 thru more recent\n> versions of \"git describe\" seem to give me the same answer.\n>\n> Anyway, I am seeing a curious symptom.\n>\n> $ git rev-list --count v2.31.0..seen\n> 716\n> $ git rev-list --count v2.31.1..seen\n> 687\n>\n> The above means that 'seen' is closer to v2.31.1 than v2.31.0; there\n> are fewer commits that are not in v2.31.1 that are in 'seen', than\n> commits that are not in v2.31.0 that are in 'seen'.\n>\n> That is naturally expected.\n>\n> $ git rev-list --count v2.31.0..v2.31.1\n> 29\n>\n> And that difference of 29 matches the difference, which is 716 - 687.\n>\n> But here is what is puzzling.\n>\n> $ git describe seen\n> v2.31.0-716-g7b65b53281\n>\n> $ git rev-list --first-parent master..seen |\n>   while read v\n>   do\n> \td=$(git describe $v)\n> \techo $v $d\n> \tcase \"$d\" in v2.31.1-*) break ;; esac\n>   done\n> 7b65b53281ae06ee25dd47dead4062125eb54427 v2.31.0-716-g7b65b53281\n> eec14f0fec886c909a29d63a94537df5a62be618 v2.31.0-714-geec14f0fec\n> ...\n> 103835562c64abef2319995716230f92092f87af v2.31.0-569-g103835562c\n> d4324831d9152b16e091646e22a6e03423a59c93 v2.31.1-516-gd4324831d9\n>\n> Is there something tricky about the topic merged at 10383556 (Merge\n> branch 'jh/rfc-builtin-fsmonitor' into seen, 2021-04-17) to confuse\n> the counting done in \"git describe\"?\n\nYou get the expected result if you only allow one or two candidates, but\nadding more of them changes that somehow.  The patch below shows the\nvalues used for sorting the candidates; the numbers in the existing\ndebug output are a bit confusing because they show the finished depth\nfor the first entry and the raw ones for the rest:\n\n   $ git describe --debug 103835562c --candidates=2\n   describe 103835562c\n   No exact match on refs or tags, searching to describe\n         472        1 v2.31.1\n         481        2 v2.31.0\n    annotated        582 v2.31.1\n    annotated        481 v2.31.0\n   traversed 3621 commits\n   more than 2 tags found; listed 2 most recent\n   gave up search at 13d7ab6b5d7929825b626f050b62a11241ea4945\n   v2.31.1-582-g103835562c\n\n   $ git describe --debug 103835562c --candidates=3\n   describe 103835562c\n   No exact match on refs or tags, searching to describe\n         496        2 v2.31.0\n         499        1 v2.31.1\n         524        3 v2.31.0-rc2\n    annotated        569 v2.31.0\n    annotated        499 v2.31.1\n    annotated        524 v2.31.0-rc2\n   traversed 3621 commits\n   more than 3 tags found; listed 3 most recent\n   gave up search at f01623b2c9d14207e497b21ebc6b3ec4afaf4b46\n   v2.31.0-569-g103835562c\n\nWhy do the depths change if we add another candidate?  I guess that's\nbecause this loop can increase the depth of each candidate for\nunflagged commits:\n\n                for (cur_match = 0; cur_match < match_cnt; cur_match++) {\n                        struct possible_tag *t = &all_matches[cur_match];\n                        if (!(c->object.flags & t->flag_within))\n                                t->depth++;\n                }\n\nAdding v2.31.0-rc2 increases the depth of v2.31.0 from 481 by 15 to 496\nand of v2.31.1 from 472 by 27 to 499.  We can print the IDs of those\nunflagged objects like this:\n\n                for (cur_match = 0; cur_match < match_cnt; cur_match++) {\n                        struct possible_tag *t = &all_matches[cur_match];\n                        if (!(c->object.flags & t->flag_within)) {\n                                t->depth++;\n\t\t\t\tif (match_cnt == 3)\n\t\t\t\t\tfprintf(stderr, \"%s %s\\n\",\n\t\t\t\t\t\toid_to_hex(&c->object.oid),\n\t\t\t\t\t\tt->name->path);\n\t\t\t}\n                }\n\nWe can then get the commits that increase the depth of v2.31.0, but not\nof v2.31.1, when we add the third candidate, v2.31.0-rc2, using\nsomething like this:\n\n   $ awk '$2 == \"v2.31.0\" {print $1}' err |\n     grep -v -f <(awk '$2 == \"v2.31.1\" {print $1}' err) |\n     git show --oneline --no-patch --stdin\n\n   68b5c3aa48 Makefile: update 'make fuzz-all' docs to reflect modern clang\n   241b5d3ebe fix xcalloc() argument order\n   93c3d297b5 git mv foo FOO ; git mv foo bar gave an assert\n\nAnd vice versa, the fifteen commits that increase the depth of v2.31.1,\nbut not of v2.31.0:\n\n   834845142d l10n: de.po: Update German translation for Git v2.31.0\n   408985d301 l10n: pt_PT: add Portuguese translations part 1\n   1369935987 l10n: vi.po(5104t): for git v2.31.0 l10n round 2\n   b0adcc311b l10n: es: 2.31.0 round 2\n   c21ad4d941 l10n: Add translation team info\n   8c4abfb8be l10n: start Indonesian translation\n   8278f87022 l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)\n   2f176de687 l10n: bg.po: Updated Bulgarian translation (5104t)\n   1ecef023a9 Merge branch 'fr_next' of github.com:jnavila/git\n   5b888ad949 Merge branch 'master' of github.com:nafmo/git-l10n-sv\n   068cb92300 l10n: fr: v2.31 rnd 2\n   f6a7e896b8 l10n: tr: v2.31.0-rc1\n   929dc48e96 l10n: sv.po: Update Swedish translation (5104t0f0u)\n   9b7e82b940 l10n: git.pot: v2.31.0 round 2 (9 new, 8 removed)\n   4dd8469336 Merge branch 'master' of github.com:git/git\n\nThat matches the observation above that the depth of v2.31.1 was\nincreased by twelve more than the depth of v2.31.0.\n\nAnd at that point I'm lost because I have no idea why adding\nv2.31.0-rc2 should increase the depth of v2.31.0 and v2.31.1\ndifferently.\n\nRené\n\n\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex 40482d8e9f..24d7a8a9cb 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -432,6 +432,14 @@ static void describe_commit(struct object_id *oid, struct strbuf *dst)\n\n \tQSORT(all_matches, match_cnt, compare_pt);\n\n+\tif (debug) {\n+\t\tfor (cur_match = 0; cur_match < match_cnt; cur_match++) {\n+\t\t\tstruct possible_tag *t = &all_matches[cur_match];\n+\t\t\tfprintf(stderr, \" %8d %8d %s\\n\",\n+\t\t\t\tt->depth, t->found_order, t->name->path);\n+\t\t}\n+\t}\n+\n \tif (gave_up_on) {\n \t\tcommit_list_insert_by_date(gave_up_on, &list);\n \t\tseen_commits--;\n"},{"id":"422210","messageId":"41392642-d4ff-7a0f-f92c-ea78f4a0b0e1@gmail.com","threadId":"55511","inReplyTo":"5cb071aa-16d1-8ea8-39e7-a0f5b89cbf3a@web.de","subject":"Re: [BUG?] 'git describe seen'?","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-04-18T13:27:03Z","receivedAt":"2021-04-18T13:27:11Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 18/04/21 17.26, René Scharfe wrote:\n> And vice versa, the fifteen commits that increase the depth of v2.31.1,\n> but not of v2.31.0:\n> \n>     834845142d l10n: de.po: Update German translation for Git v2.31.0\n>     408985d301 l10n: pt_PT: add Portuguese translations part 1\n>     1369935987 l10n: vi.po(5104t): for git v2.31.0 l10n round 2\n>     b0adcc311b l10n: es: 2.31.0 round 2\n>     c21ad4d941 l10n: Add translation team info\n>     8c4abfb8be l10n: start Indonesian translation\n>     8278f87022 l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)\n>     2f176de687 l10n: bg.po: Updated Bulgarian translation (5104t)\n>     1ecef023a9 Merge branch 'fr_next' of github.com:jnavila/git\n>     5b888ad949 Merge branch 'master' of github.com:nafmo/git-l10n-sv\n>     068cb92300 l10n: fr: v2.31 rnd 2\n>     f6a7e896b8 l10n: tr: v2.31.0-rc1\n>     929dc48e96 l10n: sv.po: Update Swedish translation (5104t0f0u)\n>     9b7e82b940 l10n: git.pot: v2.31.0 round 2 (9 new, 8 removed)\n>     4dd8469336 Merge branch 'master' of github.com:git/git\n> \n> That matches the observation above that the depth of v2.31.1 was\n> increased by twelve more than the depth of v2.31.0.\n\nDid you mean fifteen commits between v2.31.1 and v2.31.0? If so it's\nillogical, because these commits (from git-po workflow) were merged\non rc1-rc2 of v2.31.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"}]}