Feature request: commit count in git-describe should use a different method

Feature request: commit count in git-describe should use a different method

[Robin Munn]

Several people (including me) seem to expect git-describe's commit
count to be calculated differently than how it's actually calculated.
For example, see the following three Stack Overflow questions:

http://stackoverflow.com/questions/31852885/git-describe-inexplicable-commit-count
http://stackoverflow.com/questions/33116182/can-i-change-how-git-describe-counts-commits
http://stackoverflow.com/questions/13568372/commit-count-calculation-in-git-describe

The scenario that all three questions is asking about is the following:

1) I'm working along on a branch whose most recent tag is v1.1,
created 96 commits ago.
2) Someone else merges some work into master, and tags with v1.2. I
want to incorporate their work into my own, so I merge master into my
branch.
3) I now have a branch that is one commit "forward" from tag v1.2. I
therefore expect git-describe to say "v1.2-1-g1234567". Instead, I get
"v1.2-97-g1234567".

Now, git-describe is working precisely as documented here. The
documentation describes the commit count as being "the number of
commits which would be displayed by 'git log (tag commit)..(described
commit)' " and that is indeed what I'm getting. If I do "git log
v1.2..HEAD", there will be 97 log entries, because the latest commit
that is an ancestor of both v1.2 and HEAD is where my branch was
created from master 97 commits ago.

However, this is unexpected behavior for me. I was expecting to get a
commit count of 1, not a commit count of 97. Instead of a count of all
the commits since I forked from master 97 commits ago, I was expecting
a count of all the commits since the tag that git-describe has picked
as the latest tag. In other words, instead of the count to match "git
log v1.2..HEAD", I was expecting the count to match "git log
--ancestry-path v1.2..HEAD".

As shown by the Stack Overflow questions above (one of which is mine),
I am not alone in finding this behavior to be surprising. I would like
to request that git-describe acquire an additional option,
"--ancestry-path", to use the same method as "git log --ancestry-path"
to count commits. I would prefer that this become the default, but I
realize that that might be a breaking change (some people might have
build scripts that relied on git-describe's current behavior).

This is either a bug report or a feature request, depending on how
intended the current commit-count behavior is.

I've reproduced this behavior on both older versions of git (1.9.1)
and recent versions (2.6.2).

-- 
Robin Munn
Robin.Munn@gmail.com
GPG key 0x4543D577

Re: Feature request: commit count in git-describe should use a different method

[Mike Hommey]

On Wed, Nov 04, 2015 at 12:11:27PM +0700, Robin Munn wrote:
> Several people (including me) seem to expect git-describe's commit
> count to be calculated differently than how it's actually calculated.
> For example, see the following three Stack Overflow questions:
> 
> http://stackoverflow.com/questions/31852885/git-describe-inexplicable-commit-count
> http://stackoverflow.com/questions/33116182/can-i-change-how-git-describe-counts-commits
> http://stackoverflow.com/questions/13568372/commit-count-calculation-in-git-describe
> 
> The scenario that all three questions is asking about is the following:
> 
> 1) I'm working along on a branch whose most recent tag is v1.1,
> created 96 commits ago.
> 2) Someone else merges some work into master, and tags with v1.2. I
> want to incorporate their work into my own, so I merge master into my
> branch.
> 3) I now have a branch that is one commit "forward" from tag v1.2. I
> therefore expect git-describe to say "v1.2-1-g1234567". Instead, I get
> "v1.2-97-g1234567".
> 
> Now, git-describe is working precisely as documented here. The
> documentation describes the commit count as being "the number of
> commits which would be displayed by 'git log (tag commit)..(described
> commit)' " and that is indeed what I'm getting. If I do "git log
> v1.2..HEAD", there will be 97 log entries, because the latest commit
> that is an ancestor of both v1.2 and HEAD is where my branch was
> created from master 97 commits ago.
> 
> However, this is unexpected behavior for me. I was expecting to get a
> commit count of 1, not a commit count of 97. Instead of a count of all
> the commits since I forked from master 97 commits ago, I was expecting
> a count of all the commits since the tag that git-describe has picked
> as the latest tag. In other words, instead of the count to match "git
> log v1.2..HEAD", I was expecting the count to match "git log
> --ancestry-path v1.2..HEAD".

If your branch had been merged into v1.2, and you merged v1.2 back, then
you would have a lower count. One way to look at it is that the count
tells you how much your branch differs from the tag, and 97 is a more
realistic indicator of the amount of difference between the tag and your
branch head than 1 would be.

I, for one, would be confused if the count was 1.

Mike