{"thread":{"id":"40722","subject":"Feature request: commit count in git-describe should use a different method","startedAt":"2015-11-04T05:11:27Z","lastAt":"2015-11-04T05:50:18Z","messageCount":2,"participants":["Robin Munn","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"272884","messageId":"CAH=MseKsTvcWxLcVE3hdcJd3aXbn1GZA4=9zEyoCSvYT4L=yPQ@mail.gmail.com","threadId":"40722","inReplyTo":null,"subject":"Feature request: commit count in git-describe should use a different method","fromName":"Robin Munn","fromEmail":"robin.munn@gmail.com","sentAt":"2015-11-04T05:11:27Z","receivedAt":"2015-11-04T05:11:27Z","isPatch":false,"sender":{"key":"robin.munn@gmail.com","avatar":null},"body":"Several people (including me) seem to expect git-describe's commit\ncount to be calculated differently than how it's actually calculated.\nFor example, see the following three Stack Overflow questions:\n\nhttp://stackoverflow.com/questions/31852885/git-describe-inexplicable-commit-count\nhttp://stackoverflow.com/questions/33116182/can-i-change-how-git-describe-counts-commits\nhttp://stackoverflow.com/questions/13568372/commit-count-calculation-in-git-describe\n\nThe scenario that all three questions is asking about is the following:\n\n1) I'm working along on a branch whose most recent tag is v1.1,\ncreated 96 commits ago.\n2) Someone else merges some work into master, and tags with v1.2. I\nwant to incorporate their work into my own, so I merge master into my\nbranch.\n3) I now have a branch that is one commit \"forward\" from tag v1.2. I\ntherefore expect git-describe to say \"v1.2-1-g1234567\". Instead, I get\n\"v1.2-97-g1234567\".\n\nNow, git-describe is working precisely as documented here. The\ndocumentation describes the commit count as being \"the number of\ncommits which would be displayed by 'git log (tag commit)..(described\ncommit)' \" and that is indeed what I'm getting. If I do \"git log\nv1.2..HEAD\", there will be 97 log entries, because the latest commit\nthat is an ancestor of both v1.2 and HEAD is where my branch was\ncreated from master 97 commits ago.\n\nHowever, this is unexpected behavior for me. I was expecting to get a\ncommit count of 1, not a commit count of 97. Instead of a count of all\nthe commits since I forked from master 97 commits ago, I was expecting\na count of all the commits since the tag that git-describe has picked\nas the latest tag. In other words, instead of the count to match \"git\nlog v1.2..HEAD\", I was expecting the count to match \"git log\n--ancestry-path v1.2..HEAD\".\n\nAs shown by the Stack Overflow questions above (one of which is mine),\nI am not alone in finding this behavior to be surprising. I would like\nto request that git-describe acquire an additional option,\n\"--ancestry-path\", to use the same method as \"git log --ancestry-path\"\nto count commits. I would prefer that this become the default, but I\nrealize that that might be a breaking change (some people might have\nbuild scripts that relied on git-describe's current behavior).\n\nThis is either a bug report or a feature request, depending on how\nintended the current commit-count behavior is.\n\nI've reproduced this behavior on both older versions of git (1.9.1)\nand recent versions (2.6.2).\n\n-- \nRobin Munn\nRobin.Munn@gmail.com\nGPG key 0x4543D577\n"},{"id":"272885","messageId":"20151104055018.GA13077@glandium.org","threadId":"40722","inReplyTo":"CAH=MseKsTvcWxLcVE3hdcJd3aXbn1GZA4=9zEyoCSvYT4L=yPQ@mail.gmail.com","subject":"Re: Feature request: commit count in git-describe should use a different method","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-11-04T05:50:18Z","receivedAt":"2015-11-04T05:50:18Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Nov 04, 2015 at 12:11:27PM +0700, Robin Munn wrote:\n> Several people (including me) seem to expect git-describe's commit\n> count to be calculated differently than how it's actually calculated.\n> For example, see the following three Stack Overflow questions:\n> \n> http://stackoverflow.com/questions/31852885/git-describe-inexplicable-commit-count\n> http://stackoverflow.com/questions/33116182/can-i-change-how-git-describe-counts-commits\n> http://stackoverflow.com/questions/13568372/commit-count-calculation-in-git-describe\n> \n> The scenario that all three questions is asking about is the following:\n> \n> 1) I'm working along on a branch whose most recent tag is v1.1,\n> created 96 commits ago.\n> 2) Someone else merges some work into master, and tags with v1.2. I\n> want to incorporate their work into my own, so I merge master into my\n> branch.\n> 3) I now have a branch that is one commit \"forward\" from tag v1.2. I\n> therefore expect git-describe to say \"v1.2-1-g1234567\". Instead, I get\n> \"v1.2-97-g1234567\".\n> \n> Now, git-describe is working precisely as documented here. The\n> documentation describes the commit count as being \"the number of\n> commits which would be displayed by 'git log (tag commit)..(described\n> commit)' \" and that is indeed what I'm getting. If I do \"git log\n> v1.2..HEAD\", there will be 97 log entries, because the latest commit\n> that is an ancestor of both v1.2 and HEAD is where my branch was\n> created from master 97 commits ago.\n> \n> However, this is unexpected behavior for me. I was expecting to get a\n> commit count of 1, not a commit count of 97. Instead of a count of all\n> the commits since I forked from master 97 commits ago, I was expecting\n> a count of all the commits since the tag that git-describe has picked\n> as the latest tag. In other words, instead of the count to match \"git\n> log v1.2..HEAD\", I was expecting the count to match \"git log\n> --ancestry-path v1.2..HEAD\".\n\nIf your branch had been merged into v1.2, and you merged v1.2 back, then\nyou would have a lower count. One way to look at it is that the count\ntells you how much your branch differs from the tag, and 97 is a more\nrealistic indicator of the amount of difference between the tag and your\nbranch head than 1 would be.\n\nI, for one, would be confused if the count was 1.\n\nMike\n"}]}