Wrong commit count when release branch is deleted

[LordMike]

Hi,

I thought #1635 would have fixed this, but it doesn't seem like it in dotnet-gitversion version 5.0.0-beta.2+95.Branch.master.Sha.080d4598865e8e0c5dbdb017cacf4171cd37eb69.

We've observed that we get different outputs from GitVersion, depending on the presence of a release/x.y.z branch or not - even when that release branch has been merged into the local branch.

• With the release branch present (it sits on a commit just before being merged in both develop and master), we have 183 commits
• With no release branch (but still have tags, merges etc..), we get 172 commits.

What I'm really wondering about, is how the presence of a branch in a line of commits that already should be accounted for in the counting logic ... changes the source commit id.

The logs below are outputs from dotnet-gitversion /diag, on develop with no remotes (deleted to reduce errors), with and without a release branch:

• w/ Release branch, develop produces 183 commits -- log: gives-183.txt
• wo/ Release branch, develop produces 172 commits -- log: gives-172.txt

Note: We use 4 components in our versioning, as we control the first three for human purposes, and then let GitVersion control the last component.

[asbjornu]

Yes. As I write in #1526 (comment), we need to implement a more sophisticated commit counter based on walking the nodes instead of relying on Git (and LibGit2Sharp's) built-in intelligence in order to get this to work properly. As always, we welcome pull requests. 😃

[rikoe]

Hi. When will this issue be fully addressed? We are currently using GitVersion 4.0.0 (i.e. the stable release), where it occurs every time we delete a branch (which is the exact workflow described in the documentation). In 5.0.0-beta it is less common, but it can still happen.

It is immensely problematic especially for building nuget packages if the commit count goes backwards.

[asbjornu]

We have no concrete plans of addressing this, I'm afraid. We welcome pull request, though.

[rikoe]

I am a bit surprised to be honest, while at the same time realising this is an open source project and therefore "please submit a PR" is a perfectly reasonable answer. But you could argue that GitVersion as a whole is a bit broken until this is fixed.

Our develop branch nuget packages have just gone from 1.2.0-alpa0026 back down to 1.2.0-alpha0005 after merging and deleting the 1.1 release branch. Meaning the latest code is now no longer in the latest nuget package!

Unfortunately I am not that well versed in git or GitVersion, so it would be a bit hard for me to do a PR at the moment.

[asbjornu]

How about doing a git tag on the merge-commit of the release branch before the release branch is deleted?

[rikoe]

I have contemplated this and we may end up doing it, but currently we rely on GitFlow and what is described here: https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/

Our labels are stamped automatically at build time based on GitVersion, not the other way round. I.e. the release branch would generate 1.1.0-beta labels and the master branch 1.1.0 once the release branch is merged in. I believe this is a pretty standard way to do it?

[asbjornu]

I see. GitVersion sort of expects tagging to be a manual, explicit action, as that's the primary source of version information and what's considered as a way to declare "this is shipable code". When GitVersion is used to derive a version number which is then used as a label (this sounds like TeamCity jargon and is therefore a git tag, correct?), the whole problem is turned on its head and GitVersion doesn't have anything stable to predict a version number from anymore, since the process you describe asks GitVersion to find a version number for itself, by itself.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.