Closed
Description
Describe the bug
Hello again dear GitVersion maintainers :)
When getting the changes from the develop branch on top of an existing release branch, the commit counting of develop drops as the Merge Base commit changes.
Expected Behavior
The commit counting on develop should never drop, otherwise this generates overlapping build numbers.
Actual Behavior
[Test]
public void MergingDevelopToReleaseBranchShouldNotResetCommitCounterOfDevelop()
{
using var fixture = new EmptyRepositoryFixture();
fixture.MakeATaggedCommit("2.0.0");
fixture.BranchTo("release/3.0.0");
fixture.BranchTo("develop");
fixture.Repository.MakeCommits(8); // on develop
fixture.AssertFullSemver("3.1.0-alpha.8");
// work on a beta release
fixture.Checkout("release/3.0.0");
fixture.Repository.MakeCommits(20);
fixture.AssertFullSemver("3.0.0-beta.1+20");
// Finalize beta
fixture.ApplyTag("3.0.0-beta.1");
fixture.AssertFullSemver("3.0.0-beta.1");
// and start new one
fixture.Repository.MakeCommits(2);
// Counting commits from MergeBase of develop and release/3.0.0
// counting from the 3.0.0-beta.1 would be better, but this is still ok
fixture.AssertFullSemver("3.0.0-beta.2+22"); // 3.0.0-beta.2+2 would be better
// we now want to get the changes from develop onto release/3.0.0 for the 2nd beta
fixture.MergeNoFF("develop");
fixture.AssertFullSemver("3.0.0-beta.2+23"); // Ok cool
// ok, let's look at develop
fixture.Checkout("develop");
// eh, wait what? Why has the version jumped back from 3.1.0 to 2.1.0?!!
fixture.AssertFullSemver("2.1.0-alpha.8");
// eh, ok, an extra commit should fix that
fixture.MakeACommit();
// what?! Why do we reset back to alpha.1?! This will collide with a previous versions!!!
fixture.AssertFullSemver("3.1.0-alpha.1"); // expecting 3.1.0-alpha.9
}Workaround
[Test]
public void WorkaroundThisBehaviorByUsingDifferentVersions()
{
using var fixture = new EmptyRepositoryFixture();
fixture.MakeATaggedCommit("2.0.0");
fixture.BranchTo("master");
fixture.BranchTo("release/3.0.0");
fixture.BranchTo("develop");
fixture.Repository.MakeCommits(8); // on develop
fixture.AssertFullSemver("3.1.0-alpha.8");
// work on a beta release
fixture.Checkout("release/3.0.0");
fixture.Repository.MakeCommits(20);
fixture.AssertFullSemver("3.0.0-beta.1+20");
// finalize the 3.0.0 beta
fixture.Checkout("develop");
fixture.MergeNoFF("release/3.0.0");
fixture.Repository.Branches.Remove("release/3.0.0");
fixture.AssertFullSemver("3.1.0-alpha.29");
// start the 3.0.1 beta
fixture.BranchTo("release/3.0.1");
fixture.Repository.MakeCommits(10);
fixture.AssertFullSemver("3.0.1-beta.1+10");
// finalize the 3.0.1 beta and release it
fixture.Checkout("develop");
fixture.MergeNoFF("release/3.0.1");
fixture.Repository.Branches.Remove("release/3.0.1");
fixture.AssertFullSemver("3.1.0-alpha.40");
fixture.Checkout("master");
fixture.MergeNoFF("develop");
fixture.AssertFullSemver("3.0.1+12");
}Context
Creating a beta tag (e.g. 3.0.0-beta.1) is then only useful if the develop and the release branches are completely independent.
I'm not sure how we could implement a fix for this. Finding the base commit from which the metadata value is currently calculated using the vanilla MergeBase functionality of git, which finds the shortest intersection of 2 branches.
Any ideas?