Force GitVersion to ignore commits before it was introduced

[rcdailey]

I have done a lot of reading in the repo and I understand that by design, GitVersion will always choose the highest version number it calculates. However, I find this behavior very frustrating and I'm not able to get the result that I want.

I'm using v5.10.3. Here is my GitVersion.yml:

mode: MainLine
major-version-bump-message: "^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?(!:|:.*\\n\\n((.+\\n)+\\n)?BREAKING CHANGE:\\s.+)"
minor-version-bump-message: "^(feat)(\\([\\w\\s-]*\\))?:"
patch-version-bump-message: "^(build|chore|ci|docs|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?:"

And the git log:

When I run gitversion I expect version 0.1.1, but instead I get 1.0.3. It appears that it continues to count commits before the tagged commit, which I wasn't wanting it to do.

Here are the logs of gitversion /diag:

INFO [11/04/22 14:51:00:18] Working directory: C:\code\Monitor.Deployment\src\Monitor.Deployment.Client
INFO [11/04/22 14:51:00:20] Project root is: C:\code\Monitor.Deployment\
INFO [11/04/22 14:51:00:20] DotGit directory is: C:\code\Monitor.Deployment\.git
INFO [11/04/22 14:51:00:20] Branch from build environment:
INFO [11/04/22 14:51:00:23] Using latest commit on specified branch
INFO [11/04/22 14:51:00:36] Running against branch: master (e17b7c2 Merged PR 7712: GitVersion support)
INFO [11/04/22 14:51:00:36] Begin: Calculating base versions
  INFO [11/04/22 14:51:00:38] Fallback base version: 0.1.0 with commit count source 087d75f8e55d5fdea1f0e20d9c8151da447729a6
  INFO [11/04/22 14:51:00:44] Git tag 'v0.1.0': 0.1.0 with commit count source 97d8e2916675f062b56e586a9139f957156d9cc4
  INFO [11/04/22 14:51:00:49] Found multiple base versions which will produce the same SemVer (0.1.1), taking oldest source for commit counting (Fallback base version)
  INFO [11/04/22 14:51:00:49] Base version used: Fallback base version: 0.1.0 with commit count source 087d75f8e55d5fdea1f0e20d9c8151da447729a6
  INFO [11/04/22 14:51:00:49] End: Calculating base versions (Took: 128.55ms)
  INFO [11/04/22 14:51:00:50] 38 commits found between 087d75f chore: gitattributes and gitignore and e17b7c2 Merged PR 7712: GitVersion support
  INFO [11/04/22 14:51:00:50] Begin: Using mainline development mode to calculate current version
    INFO [11/04/22 14:51:00:51] '^master$|^main$' does not match 'dev/rcd/api-key-auth'.
    INFO [11/04/22 14:51:00:51] '^support[/-]' does not match 'dev/rcd/api-key-auth'.
    INFO [11/04/22 14:51:00:51] '^master$|^main$' does not match 'dev/rcd/client-library'.
    INFO [11/04/22 14:51:00:51] '^support[/-]' does not match 'dev/rcd/client-library'.
    INFO [11/04/22 14:51:00:51] '^master$|^main$' matches 'master'.
    INFO [11/04/22 14:51:00:52] Found merge base e17b7c29f297ada956dfedd9d2cde2c2c03b07a4 for 'master'.
    INFO [11/04/22 14:51:00:52] '^master$|^main$' does not match 'HEAD'.
    INFO [11/04/22 14:51:00:53] '^support[/-]' does not match 'HEAD'.
    INFO [11/04/22 14:51:00:53] '^master$|^main$' matches 'master'.
    INFO [11/04/22 14:51:00:53] Found merge base e17b7c29f297ada956dfedd9d2cde2c2c03b07a4 for 'origin/master'.
    INFO [11/04/22 14:51:00:53] Found possible mainline branches: master, origin/master
    INFO [11/04/22 14:51:00:54] Choosing master as mainline because it is the current branch
    INFO [11/04/22 14:51:00:55] Direct commit on main 7d411e5 refactor: Initial Web API project incremented base versions Patch, now 0.1.1
    INFO [11/04/22 14:51:00:55] Merge commit 0474f35 Merged PR 7610: Some fixups to the initial project incremented base versions Patch, now 0.1.2
    INFO [11/04/22 14:51:00:55] Merge commit f7ce387 Merged PR 7621: refactor: Move service registration into CompositionRoot class incremented base versions Patch, now 0.1.3
    INFO [11/04/22 14:51:00:55] Merge commit 551c6c4 Merged PR 7627: build: Actually enable central package management incremented base versions Patch, now 0.1.4
    INFO [11/04/22 14:51:00:55] Merge commit 0daf62d Merged PR 7630: Repo checklist items incremented base versions Patch, now 0.1.5
    INFO [11/04/22 14:51:00:56] Merge commit 90d529e Merged PR 7632: Pipeline + skeleton for unit tests incremented base versions Patch, now 0.1.6
    INFO [11/04/22 14:51:00:56] Merge commit 65a483b Merged PR 7641: Code style change, UTF-8 adjustments, URL format change incremented base versions Major, now 1.0.0
    INFO [11/04/22 14:51:00:56] Merge commit 1769ba1 Merged PR 7674: Docker support incremented base versions Patch, now 1.0.1
    INFO [11/04/22 14:51:00:56] Merge commit 97d8e29 Merged PR 7694: ci: Fix inconsistent architecture for docker build incremented base versions Patch, now 1.0.2
    INFO [11/04/22 14:51:00:56] Merge commit e17b7c2 Merged PR 7712: GitVersion support incremented base versions Patch, now 1.0.3
    INFO [11/04/22 14:51:00:57] 38 commits found between 087d75f chore: gitattributes and gitignore and e17b7c2 Merged PR 7712: GitVersion support
  INFO [11/04/22 14:51:00:57] End: Using mainline development mode to calculate current version (Took: 70.11ms)

Of particular interest is this bit:

Fallback base version: 0.1.0 with commit count source 087d75f8e55d5fdea1f0e20d9c8151da447729a6
Git tag 'v0.1.0': 0.1.0 with commit count source 97d8e2916675f062b56e586a9139f957156d9cc4
Found multiple base versions which will produce the same SemVer (0.1.1), taking oldest source for commit counting (Fallback base version)

My understanding is that PR #3078 should have prevented GitVersion from looking at commits before the last tag. I'm trying to force GitVersion to use a zero-based major version until I'm ready to formally release the API. There's no first-class mechanism to support this, so I've just tried to be careful about not introducing BREAKING CHANGE / feat! or similar type commits. However, there are commits prior to the introduction of GitVersion that unfortunately were done wrong, and those impact the major version when I do not want them to.

To make things worse, I tried this but these settings seem to have no impact:

ignore:
  sha:
    - 2367e68525f5ac12e65849c7c6ddfea1b79a3118
    - 65a483ba12a06f971f40aaecb68ffb5446d299d3
  commits-before: "2022-10-07T13:59:10"

How can I get the version to be 0.x.y again using Mainline mode?

[asbjornu]

How does removing mode: Mainline affect the ignore behavior?

[rcdailey]

I'm not sure, to be honest, even if it did affect the behavior I would not be able to accept that change. Based on our branching model we must use mainline mode.

[asbjornu]

If you have a branching model, I would say you don't need Mainline. Care to elaborate?

[rcdailey]

Having only a mainline, to me, is a branching model. But I see where the confusion lies. I didn't mean to imply I use something like GitFlow.

Every change on master is a release. We use shortlived topic branches for purposes of pull requests and code review, which get rebased & merged into master. That's it.

I could go back and test without the mode: Mainline as you requested, but that would take me some time. It's been over a month since I posted this question and the project has developed quite rapidly during that time. I'd have to reconstruct this scenario again locally.

[asbjornu]

It would be very helpful to know whether the behavior changes if you remove mode: Mainline because as it currently looks, Mainline is going to be removed in v6.

[rcdailey]

What is the semantic replacement for Mainline in v6?