{"thread":{"id":"39716","subject":"[BUG] git describe returns wrong tag as closest tag","startedAt":"2015-06-25T07:20:25Z","lastAt":"2015-06-25T07:20:25Z","messageCount":1,"participants":["Mikael Knutsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"264806","messageId":"CADVPA6CXqr6yuQ5Mb_vyhtrfin1jQskF6YDTRZWVHfQjZrnwng@mail.gmail.com","threadId":"39716","inReplyTo":null,"subject":"[BUG] git describe returns wrong tag as closest tag","fromName":"Mikael Knutsson","fromEmail":"mikael.knutsson@quinyx.com","sentAt":"2015-06-25T07:20:25Z","receivedAt":"2015-06-25T07:20:25Z","isPatch":false,"sender":{"key":"mikael.knutsson@quinyx.com","avatar":null},"body":"Hi!\n\nI've discovered that if you have two non-rewinding branches that you\nmerge between you can get the wrong tag as closest tag if the\nCOMMITTER_DATE of any of the commits after the branch split is before\nthe date of the branch split. You can end up in this state simply by\nhaving a committer doing a rebase after a branch split and pushing\ntheir code. (This is an assumption of what happened when we saw the\nbehaviour)\n\nReproduction case:\nmkdir testcase\ncd testcase\ngit init\ngit commit --allow-empty -m init\ngit tag -a -m 'Test tag 1' 1\ngit branch tagerror\ngit checkout tagerror\ngit commit --allow-empty -m test01\ngit commit --allow-empty -m test02\ngit checkout master\nGIT_COMMITTER_DATE=`date --date '-10 min'` git commit --allow-empty -m\ntest03 # this is what causes the error\ngit tag -a -m 'Test tag 2' 2\ngit checkout tagerror\ngit commit --allow-empty -m test04\ngit checkout master\ngit merge --no-ff tagerror\ngit describe --long # (expected output is '2-4-COMMITHASH', output is\n'1-5-COMMITHASH')\n\nIf you remove the GIT_COMMITTER_DATE from the repro, you'll notice\nthat you get the expected output.\nYou can verify the ANY part by adding a commit on each branch before\nthe COMMITTER_DATE like this:\nmkdir testcase\ncd testcase\ngit init\ngit commit --allow-empty -m init\ngit tag -a -m 'Test tag 1' 1\ngit branch tagerror\ngit checkout tagerror\ngit commit --allow-empty -m test01\ngit commit --allow-empty -m test02\ngit commit --allow-empty -m test03\ngit checkout master\ngit commit --allow-empty -m test04\ngit tag -a -m 'Test tag 2' 2\nGIT_COMMITTER_DATE=`date --date '-10 min'` git commit --allow-empty -m\ntest05 # this is what causes the error\ngit checkout tagerror\ngit commit --allow-empty -m test06\ngit checkout master\ngit merge --no-ff tagerror\ngit describe --long # (expected output is '2-4-COMMITHASH', output is\n'1-5-COMMITHASH')\n\nIf you run a \"git describe --long --first-parent\", you'll notice that\nit does actually pick up the correct tag in both above cases.\n\nIt seems to me that in the source code for describe, it relies on\nsorting the commits on a strict date basis, rather than sorting them\nin traversal order:\nhttps://github.com/git/git/blob/master/builtin/describe.c#L204\n\nCaveats to the reproduction case:\nIn our \"real\" case, the date of the commit causing the issue is before\nthe last commit before the branch split, but not before the root\ncommit nor before tag \"1\" in the repro case.\nThe distance to the tag that is erroneously picked up is much greater\nthan the closest tag (around 1200 commits more).\n\nI'm sadly not very well-versed in C nor in the Git source code, so I'm\nnot sure how the appropriate fix would look like - that's why I'm not\nalso submitting a patch to fix this. :)\n\n// Mikael K.\n"}]}