#4589 Magic strings >> BranchConfigurationKey.

May I ask you: Why do you care about how the branch is named in the unit tests? Does it make any different if it is named master or main? From the configuration point of view both are included and treated the same. At the end everyone can use their own name and their own configuration in the unit tests. There is no need for unification IMO.

Problem 1:

• 1.3.0-f2.1+1 is what the test asserts
• 1.3.0-f2.1+0 is what I observe when I run dotnet-gitversion 6.3.0

I have executed gitversion (6.3.0) after the test step you mentioned and got 1.3.0-f2.1+1:

image

Problem 2:

• Before rebase 1.3.0-f2.1+1 is what the test asserts (but not what dotnet-gitversion produces - see Problem 1).
• After rebase 1.3.0-f2.1+3 is what both tests and dotnet-gitversion 6.3.0 produce.

I'd have anticipated1.3.0-f2.1+1 both before and after rebase, in this specific scenario.

The status of the repository is not the same and the information Gitversion uses to determine the next version is different:

Before rebase:
Repo_Befor_Rebase_1 3 0-f2 1+1

After rebase:
Repo_After_Rebase_1 3 0-f2 1+3

What is your point here?

Odd. If I run the test now and flip out to the command line the config that's being persisted by the test is no longer valid for running with 6.3.0 but it works for you? I'll look again when it's a more sensible o'clock.

In the meantime, as I said on my opening post, if my expectations aren't correct then I would like to understand what would be correct.
1 - The merge bumps the root version on the same f2 commit from 1.2 to 1.3; that's an expected change due to changed state, and the +0 resets since there have now been no commits since version source. All fine.
2 - I'd expected the first commit on the branch since the last version bump to be f2.1+1 as the test asserts before rebase. I concur with the test. Dotnet-gitversion 6.3.0 tbc.
3 - If I rebase that commit, yes the whole tree is different but that first commit is no longer considered the first commit on the branch since the version source? I'd not expected that.

How does +1 jump to +3? If there's documentation, point me at it as I do appreciate you've been generous with your time already.

To be fair working out how to configure the majority minor patch bumps work now is what I'd expected to be playing with in the tests, not the CommitsSinceVersionSource idiosyncrasies...

Odd. If I run the test now and flip out to the command line the config that's being persisted by the test is no longer valid for running with 6.3.0 but it works for you? I'll look again when it's a more sensible o'clock.

I have just opend my cmd-shell and executed gitversion in version 6.3.0

How does +1 jump to +3? If there's documentation, point me at it as I do appreciate you've been generous with your time already.

First of all the algorithm calcualtes the next versions by executing the differnt version strategy implementations. After that the highest increment version will be selected. If there are more then one increment with the same value, the newest base version source will be used.

In both cases (before and after the rebase) the version increment of tag 1.2.1 on main wins which will be returned by the TaggedCommitVersionStrategy class. So far so good. We can assure that the base version source is in both cases the same. Please notice that the base version source (commit) is not part of the feature branch but main branch.

The answer why a different commit count is calulcated is based in the following logic (calculating the CommitsSinceVersionSource):

Before the reabase you have only one commit which differs from the main branch. After the rebase you have three commits who are not part of main (the branch where the base version source was selected).

Hope that answers your question.

Intentionally writing out the GitVersion.yml to demonstrate inconsistency between UnitTest version calculation and running dotnet-gitversion from the commandline. Refer to 2 problems in commentary.