What am I misunderstanding - Multiple commits with version bumps and increment: None #4904
Replies: 1 comment 4 replies
-
|
I would expect 2.1.0-1 (tested with gitversion-win-x64-6.6.0) $ mkdir A-TrunkBased-Repo $ gitversion.exe -nocache {
"AssemblySemFileVer": "2.1.0.0",
"AssemblySemVer": "2.1.0.0",
"BranchName": "main",
"BuildMetaData": null,
"CommitDate": "2026-03-30",
"CommitsSinceVersionSource": 1,
"EscapedBranchName": "main",
"FullBuildMetaData": "Branch.main.Sha.cfc25377b7dc7ee61e634f61e296dc5b5d0e305a",
"FullSemVer": "2.1.0-1",
"InformationalVersion": "2.1.0-1+Branch.main.Sha.cfc25377b7dc7ee61e634f61e296dc5b5d0e305a",
"Major": 2,
"MajorMinorPatch": "2.1.0",
"Minor": 1,
"Patch": 0,
"PreReleaseLabel": "",
"PreReleaseLabelWithDash": "",
"PreReleaseNumber": 1,
"PreReleaseTag": "1",
"PreReleaseTagWithDash": "-1",
"SemVer": "2.1.0-1",
"Sha": "cfc25377b7dc7ee61e634f61e296dc5b5d0e305a",
"ShortSha": "cfc2537",
"UncommittedChanges": 1,
"VersionSourceDistance": 1,
"VersionSourceIncrement": "None",
"VersionSourceSemVer": "2.0.0-2",
"VersionSourceSha": "bcb976485098ac4705c98290bc99d0f22730a0cc",
"WeightedPreReleaseNumber": 55001
} |
Beta Was this translation helpful? Give feedback.
-
|
I tried this a few times and was increasingly confused - reproducing your steps gave me the same result as you (2.1.0), but using your config (and variations on it) for my repository continued to produce 1.5.0. I then tried to rebase my repo and adjust the commit messages (although I was sure they met the regex requirements) and got 2.1.0. Finally, I added sleep commands between my git commits during the repo creation - and now I get 2.1.0. I suppose this doesn't matter too much, because in reality I will never make multiple commits in less than a second, but I was surprised by the behaviour... |
Beta Was this translation helpful? Give feedback.
-
|
Is it reproducable somehow? Or is the repo public available? No idea why you are getting a different result. |
Beta Was this translation helpful? Give feedback.
-
|
I invited you to access the repository - there's a tag on it a couple of commits back titled "discussion_4904" which if you checkout you can run The commit immediately after that in the history adds a delay between |
Beta Was this translation helpful? Give feedback.
-
Is it possible to provide me the native git commands or the resulting repository with failing git history? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
My basic understanding was that GitVersion first finds a "Source Version" to start from, then uses the collection of available "Strategies" to calculate what the next version should be, and then selects the highest version number.
In a test case, I have the following layout:
My configuration is set to:
I expect that the source version will be f178d0e (1.4.7) and that the calculated outcome will be 2.0.0 (the second commit includes
+semver: majorin the message).Instead, I get 1.5.0, based on the more recent d66d362 commit.
If I flip the order of the commit messages, then I get the expected result.
Probably I'm just using GitVersion incorrectly, but I'd ideally like to be able to run a build process on some but not all commits, and generate an appropriate tag version (using the SemVer or MajorMinorPatch values, ignoring the prerelease version tag which I'm using to store a separate counter in a manner which provides sorting (excluding the use of build metadata, which does not sort)).
If I add a tag with name
RT-v1.4.7to the same commit as theRT-v1.4.7-0tag, then I get the expected 2.0.0 when running GitVersion.Is this caused by some different resolution of tags in different modes? I couldn't understand the diag context:
Without extra tag:
and with the extra tag:
Beta Was this translation helpful? Give feedback.
All reactions