Unexpected value of CommitsSinceVersionSource in certain branch setup

[DmitrySenin]

In one of my projects, I have the following workflow:

1. Branches dev, qa, main are in use
2. All development is happening in dev, i.e. all features are merged in dev first
3. When all feature of the current release are done, dev gets merged into qa
4. From qa we deploy to our QA environment and verify the software there
5. If all good, qa is merged into main and we release

I've come up with the following config for GitVersion 6

workflow: ''
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
tag-prefix: '[vV]?'
tag-pre-release-weight: 60000
commit-date-format: yyyy-MM-dd
merge-message-formats: {}
update-build-number: true
semantic-version-format: Strict
strategies:
- TaggedCommit

branches:
  develop:
    regex: ^dev$
    increment: Minor
    label: alpha
    is-source-branch-for:
      - release/qa
      - feature
    prevent-increment:
      of-merged-branch: true
      when-current-commit-tagged: false

  release/qa:
    regex: ^release/qa$
    increment: None
    label: beta
    is-source-branch-for:
      - main
    prevent-increment:
      of-merged-branch: true

  main:
    mode: ContinuousDeployment
    regex: ^master$
    increment: None
    label: ''
    is-release-branch: true
    is-main-branch: true

  feature:
    increment: Inherit
    regex: (?<BranchName>(?!dev$|release\/qa$|master$).+)
    label: '{BranchName}'
  
mode: ContinuousDelivery
track-merge-target: false
track-merge-message: false
commit-message-incrementing: Disabled
regex: ''
source-branches: []
is-source-branch-for: []
tracks-release-branches: false
is-release-branch: false
is-main-branch: false

Long story short, before merging dev into qa, we tag the last commit on dev with the current version and then merge. It all works just fine and as we want. A small issue is observed in qa with regards to CommitsSinceVersionSource (and FullSemVer effectively) which creates confusion.

Here is an example

* 5c33ced (dev) first feature of 1.5.0
| *   d3ed4b7 (HEAD -> main) Merge branch 'release/qa'
| |\  
| | *   a3d45fb (qa) Merge branch 'dev' into release/qa
| | |\  
| |_|/  
|/| |   
* 23c23a9 (tag: v1.4.0) last feature of 1.4.0

• 5c33ced(dev) will produce 1.5.0-alpha.1 as expected
• d3ed4b7(main) will produce 1.4.0 as expected
• a3d45fb(qa) will produce 1.4.0-beta.8: 1.4.0-beta is expected but 8 is NOT expected here. I expect to have 1.4.0-beta.1 because it is the first commit of 1.4.0 in qa

I understand why it works this way: GitVersion runs git log 23c23a9..a3d45fb under the hood which essentially produces all commits on qa from a3d45fb backwards but still it's counter-intuitive. Running git log 23c23a9..a3d45fb --ancestry-path will produce what I'm after - 1

I'm wondering if anyone has come across something similar and if there is a workaround for this? And if it makes sense to introduce an ability to achieve the more intuitive behaviour?

[HHobeck]

No, this is not possible. You can find the logic at the following location:

GitVersion/src/GitVersion.Core/VersionCalculation/VersionCalculators/VersionCalculatorBase.cs

Lines 17 to 23 in 382fa3a

	protected SemanticVersionBuildMetaData CreateVersionBuildMetaData(ICommit? baseVersionSource)
	{
	var commitLogs = this.repositoryStore.GetCommitLog(
	baseVersionSource: baseVersionSource,
	currentCommit: Context.CurrentCommit,
	ignore: Context.Configuration.Ignore
	);

I was thinking that it might be possible to create a new GitVersion variable in order to build a customized InformationalVersion (by specifying assembly-informational-format). Could you please create a PR to prove the concept?