My question is related to git describe: inexplicable commit count and commit count calculation in git-describe, but not quite identical to either question. I've been developing on a feature branch in my current project, and I've been using git describe to get version numbers for the feature branch, using the recent tag and commit count to make a version number that I thought would be monotonically increasing. (E.g., my branch is currently 96 commits ahead of v1.1.0, so I've been turning v1.1.0-96-g1234567 into "version 1.1.0.96" in the version I report to the user.)
Now, the master branch was recently tagged with v1.2.0, and I want to incorporate the changes made in version 1.2 into my feature branch. So I merged master into my feature branch, and I thought that git describe would yield v1.2.0-1-g9876543. But instead, I got v1.2.0-97-g9876543.
I understand why this is happening: as described in the Git manual, git describe is counting the commits produced by git log v1.2.0..9876543 to produce the commit count (97, because my branch had 96 commits plus the one merge commit). But what I really want is to use the result of git log --ancestry-path v1.2.0..9876543 instead, which shows just the merge commit and therefore would produce the v1.2.0-1-g9876543 result that I was expecting.
Is there any way for me to change git describe's behavior to use git log --ancestry-path v1.2.0..9876543 instead of git log v1.2.0..9876543?
And, more importantly, what is the benefit of doing it the way git describe currently does it? If I write my own tool to produce the version numbering scheme I had been expecting, what will I lose by doing so?
BTW. here's a snapshot of the git repository history, so you can see visually what I just described. The feature/cmdline branch is the one I'm working on. (This history view is from the Git Extensions tool on Windows, in case anyone's wondering.)
