Version is different on a fresh repo clone

[pbalaga]

On a certain branch in a local repo I was working on, gitversion command returns MajoMinorPatch=0.1.0. However, when I make a fresh clone of the same repo, gitversion produces 2.1.0.

Both numbers definitely make sense assuming the first repo is out-of-date. That said, I tried:

• fetching / pulling all branches in the 'out-dated' repo
• deleting .git/gitversion_cache folder

but the version remains at 0.1.0.

Am I missing the correct way to sync local repo with remote? Was does gitversion expect me to do?

[nshenoy]

Have you tried to do a git pull --tags to explicitly get the tags from the remote? Is it possible that your configs are defaulting to --no-tags ?

[pbalaga]

I tried git pull --tags on both repos and it seems to have impact only in the 'old' one (version is now 2.0.11 which is the last version tag on master). However, the versions are still not equal. (The fresh clone is still 2.1.0.)

Let me add, if it points in the right direction, that I'm using gitflow workflow and the above version numbers are generated when a feature branch is checked out.

It seems as if version number was calculated differently for the 'old' and the 'fresh' repo. I have run gitversion /diag for both clones and below are shortened outputs. Important differences:

• release branch is taken into account in the fresh clone, in the old one it is not
• gitversion increments minor version for the fresh repo, revision number for the old repo

I don't fully understand why this is happening.

'Old repo':

INFO [04/04/18 9:29:28:51] Git tag 'v2.0.10': 2.0.10 with commit count source b1ccb1c0a97c9c0e9b52888b28c2bc50fb1fd10d (Incremented: 2.0
INFO [04/04/18 9:29:28:54] Git tag 'v2.0.9': 2.0.9 with commit count source 13e882bb97282200ef81b4d53373f158d440e96d (Incremented: 2.0.1
(Cutting out excessive logs...)
INFO [04/04/18 9:29:28:81] Git tag 'v2.0': 2.0.0 with commit count source 77d11bb11ff6048d4d98fecbc8d1b11131649bf2 (Incremented: 2.0.1)

'Fresh repo':

INFO [04/04/18 9:22:40:37] Release branch exists -> Version in branch name: 2.0.0 with commit count source 0b27e604a56ec3e418959264b43241cdb1b48397 (Incremented: 2.1.0)
INFO [04/04/18 9:22:40:39] Git tag 'v2.0.11': 2.0.11 with commit count source 89709115d4887a3fd54b76176acdc1cd4809840b (Incremented: 2.1.0)
(Cutting out excessive logs...)
INFO [04/04/18 9:22:40:63] Git tag 'v2.0': 2.0.0 with commit count source 77d11bb11ff6048d4d98fecbc8d1b11131649bf2 (Incremented: 2.1.0)

[asbjornu]

The same version of GitVersion is running in both repositories? Task or .exe? Are you able to reproduce in another fresh clone?

[pbalaga]

All outputs above come from the same gitversion.exe installed via Chocolatey. (The same .exe for both repositories.) The version used is specifically:
4.0.0-beta.12+1315.Branch.master.Sha.9c70946f68973b3b31b2861913c247fbe6c3f0ec

Additionally, consistent results occur when MSBuild task is used. (GitVersionTask version="4.0.0-beta0012")

Also, I verified that another fresh clone works same as the 'previous fresh' clone.

I can of course work on one of the fresh clones from now on. That said, I am not sure why it works this way and how to avoid it in the future and what impact it may have on CI. My guess would be this is purely a git thing, but for the fact that gitversion /diag clearly describes it suggests incrementing either revision of minor number, depending on the repo.

[asbjornu]

I have no idea what might be going on here. If a fresh clone fixes the problem for you, that's an easier fix than trying to figure out the underlying reason why GitVersion is being confused.