Squash Commits and Version Calculation

[ArnavBhutaniLithia]

Hello!

I have run into some issues working with a very standard gitflow release structure as described on the GitVersion documentation: https://gitversion.net/docs/learn/branching-strategies/gitflow/

However when making squash merges or single commits to the main branch, the version calculation gets messed up.

Eg)

commit 4100fd0728b92bcb93fe1b16bd498e1a9ac03709 (HEAD -> main, tag: v1.82.0)

gitversion
{
  "Major": 1,
  "Minor": 82,
  "Patch": 0,
  ...
}

git merge release/1.83.0 --squash

git commit -m 'Merged PR 123123: Merge release/1.83.0 to main

gitversion
{
  "Major": 1,
  "Minor": 82,
  "Patch": 1,
  ...
}

This also happens on commits to main (I am aware that the docs above specify that you only merge release and hotfix branches in main, I'm just wondering if this is an intentional design or if it is not possible).

From what I understand:
https://learn.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash?view=azure-devops
Squash commits still make commits on main, so as long as the commit message format fits the defined regex it should trigger the new version. But this doesn't appear to be the case. Is there an explanation somewhere for the behavior I am observing? In the end this isn't a big deal, but I would like to make sure that my versioning scripts are as resilient as possible to user error, and if there is a way to avoid running into release failures that would be preferable.

Gitversion.yaml file:

mode: ContinuousDelivery
branches:
  main:
    is-source-branch-for:
      - develop
      - hotfix
  release:
    mode: ContinuousDeployment
    tag: rc 
    source-branches:
      - develop
  hotfix:
    mode: ContinuousDeployment
    tag: rc
    is-release-branch: true
ignore:
  sha: []
merge-message-formats:
  tfs: '^Merged (?:PR (?<PullRequestNumber>\d+)): (M|m)erge (?<SourceBranch>.+) (in)?to (?<TargetBranch>.+)'

Thanks,
Arnav

[asbjornu]

If you want to only have non-merge commits on main, you should probably use mode: Mainline instead of mode: ContinuousDelivery. We're attempting to fix this in v6 so you can get the same behaviour regardless of the chosen mode, so please try out the latest beta to see whether it works better for your use-case.

[ArnavBhutaniLithia]

Just to confirm, when you say non-merge commits, you include squash merges in that description as well?

[HHobeck]

I think the logic is located in MergeMessageVersionStrategy.cs... You can see it is only working for merge messages with two parent commits which is not the case for squash merges:

Your issu is related to the following issue in my opinion: #3689

Is there any other issue existing @asbjornu? If not maybe it is good to create a new bug or feature issue.

[ArnavBhutaniLithia]

Yes, I have noticed that no fast forward merges with just one commit also have the same issue.

As for issue #3689, I don't think it describes my issue properly.

I believe that they have set the increment on the develop branch in their GitVersion.yaml file to minor, which causes all commits/merges to develop to cause a minor version bump. That issue looks like a configuration issue.

From what you and @asbjornu are saying, this looks like this is more of an issue with the code, where there needs to be at least two commits in the ContinousDelivery mode for the version calculation to be conducted properly.

I'm happy to create a new issue if you both think that is appropriate.

[HHobeck]

If you like please create a pull request as well and fix it.