[Bug] `track-merge-changes` produces unexpected result when combining `hotfix` and `support` branches

[Crown0815]

Describe the bug

It appears that track-merge-changes does not work when combining hotfix and support branches. I have the following test

[Test]
public void MyTest()
{
    var config = new Config();
    config.Branches.Add("hotfix", new BranchConfig
    {
        TrackMergeTarget = true,
    });

    using var fixture = new EmptyRepositoryFixture();
    fixture.Repository.MakeACommit();
    fixture.Checkout(MainBranch);
    fixture.Repository.ApplyTag("1.7.0");
    
    fixture.BranchTo("hotfix/1.7");
    fixture.Repository.MakeCommits(1);
    fixture.Repository.ApplyTag("1.7.1-beta.1");

    fixture.Checkout(MainBranch);
    fixture.BranchTo("support/1.7");
    fixture.Repository.Merge(fixture.Repository.Branches["hotfix/1.7"], new Signature("a", "b", DateTimeOffset.Now-TimeSpan.FromMinutes(55)), new MergeOptions()
    {
        FastForwardStrategy = FastForwardStrategy.NoFastForward,
    });

    fixture.Repository.ApplyTag("1.7.1");

    fixture.Checkout("hotfix/1.7");
    fixture.Repository.MakeACommit("semver: bug");

    fixture.AssertFullSemver("1.7.2-beta.1", config);
}

that produces the following repository:

* d9e96de 54 minutes ago  (HEAD -> hotfix/1.7)
|   
| *  57c51f7 55 minutes ago  (tag: 1.7.1, support/1.7)
|/|   
* | 79a0af5 56 minutes ago  (tag: 1.7.1-beta.1)
|/  
* 2d1d766 58 minutes ago  (tag: 1.7.0, main)

Expected Behavior

hotfix is set to track-merge-targets = true; hence, I would expect its next version to be 1.7.2-beta.1

Actual Behavior

Running the test produces:

should be 1.7.2-beta.1
but was 1.7.1-beta.2+2

Possible Fix

I suspect the merge target tracking is incomplete, or I am not configuring GitVersion correctly.

Steps to Reproduce

See test above

Context

I am attempting to merge hotfix branches into support branches and have the version of the hotfix branches bumped without requiring a merge back from support into hotfix.

Your Environment

Standard git repository

• Version Used: 5.3.6
• Operating System and version (Windows 10):
• Link to your project: N/A
• Link to your CI build (if appropriate): N/A

[asbjornu]

I'm not sure, but I think the problem may be that the tag 1.7.1 is applied to the support/1.7 branch and not to main. I don't think support branches are considered merge targets for hotfix by default. If you apply the 1.7.1 tag to main, I think you should get the expected version 1.7.2-beta.1.

[Crown0815]

@asbjornu yes, but main is not on version 1.7.1, it is still on version 1.7.0 in our case, so that is not an option. Can merge targets be configured?

[asbjornu]

You can configure source-branches as a sort of opposite relationship to "merge target".

[HHobeck]

I'm not sure what your branching and merging strategy is exactly but it seems to be that the gitflow strategy maybe a good solution for you (see gitflow example here). Anyway if you ask me you should on the one hand create a dedicated hotfix branch from the source branch you want to place the bug fix and on the other hand create a hotfix branch with the target semantic version number (e.g. hotfix/1.7.1). At this moment you have tested your hotfix and ensure the stability of the release candidate (RC), you are going to merge the hotfix to the support branch (support/1.7) and delete the hotfix branch. That’s mean you declare this fix as resolved and released it to manufacturing (RTM) (e.g. tagging this commit with 1.7.1). Now if you have another bug (which needs to be hot fixed) you create an additional branch from the support branch with the name hotfix/1.7.2. In my opinion is this the same procedure like you would fix bugs in the main branch.

[HHobeck]

I have taken a look in to the source code of GitVersion in version 5.10.1 and cannot find any usage of the TrackMergeTarget settings. In my opinion this property is not used and should be marked as deprecated.

@asbjornu: Do you know if I have missed something?

[asbjornu]

Hm, good question, @HHobeck. I'm not using that feature myself, did not implement it, and am not sure exactly how it's supposed to work. It may be that we didn't have tests covering that feature and the affected code has just been refactored away. Perhaps the best thing to do is to deprecate it entirely in v6.

[HHobeck]

I have found the following logic changed by Jake Ginnivan in 2015 (see commit [1]):

    public class GitFlowDevelopBranchBaseVersionStrategy : HighestTagBaseVersionStrategy
    {
        protected override bool IsValidTag(GitVersionContext context, string branchName, Tag tag, Commit commit)
        {
            if (!string.IsNullOrWhiteSpace(branchName))
            {
                if (context.Configuration.TrackMergeTarget)
                {
                    return IsDirectMergeFromCommit(tag, commit);
                }
            }

            return base.IsValidTag(context, branchName, tag, commit);
        }

        static bool IsDirectMergeFromCommit(Tag tag, Commit commit)
        {
            var targetCommit = tag.Target as Commit;
            if (targetCommit != null)
            {
                var parents = targetCommit.Parents;
                if (parents != null)
                {
                    return parents
                        .Where(parent => parent != null)
                        .Any(parent => string.Equals(parent.Id.Sha, commit.Id.Sha, StringComparison.OrdinalIgnoreCase));
                }
            }

            return false;
        }
    }

The configuration properties TrackMergeTarget was used to determine base versions in the scenario where a branch has been merged into the current branch or vice versa. In the latest code base I cannot find any usage.

commit [1]:

Jake Ginnivan
Commit 1d1b0c4
Author: Jake Ginnivan jake@ginnivan.net
Date: Sunday, 15 March 2015 12:43
Parent: 1ee64bf

Switched to configuration option rather than hardcoding branch name

[HHobeck]

I would like to understand the intention of the TrackMergeTarget property. @asbjornu May be you can give me your opinion about the following scenario:

    [Test]
    public void __Just_A_Test__()
    {
        var configuration = new Config()
        {
            VersioningMode = VersioningMode.ContinuousDeployment,
            Branches = new Dictionary<string, BranchConfig>()
            {
                {
                    "develop", new BranchConfig() {
                        TrackMergeTarget = true
                    }
                }
            }
        };

        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeACommit();
        fixture.AssertFullSemver("0.1.0-ci.0", configuration);
        fixture.BranchTo("develop");
        fixture.AssertFullSemver("0.1.0-alpha.0", configuration);
        fixture.MakeACommit();
        fixture.AssertFullSemver("0.1.0-alpha.1", configuration);
        fixture.BranchTo("release/1.0.0");
        fixture.AssertFullSemver("1.0.0-beta.0", configuration);
        fixture.MakeACommit();
        fixture.AssertFullSemver("1.0.0-beta.1", configuration);
        fixture.MakeACommit();
        fixture.AssertFullSemver("1.0.0-beta.2", configuration);
        fixture.Checkout("develop");
        fixture.AssertFullSemver("0.1.0-alpha.1", configuration); // 1.1.0 expected
        fixture.MakeACommit();
        fixture.AssertFullSemver("1.1.0-alpha.1", configuration);
        fixture.MergeNoFF("release/1.0.0");
        fixture.AssertFullSemver("1.1.0-alpha.4", configuration);
        fixture.Repository.Branches.Remove("release/1.0.0");
        fixture.AssertFullSemver("1.1.0-alpha.4", configuration); // okay because TrackMergeTarget=true ??
        configuration.Branches["develop"].TrackMergeTarget = false;
        fixture.AssertFullSemver("1.1.0-alpha.4", configuration); // 0.1.0 expected because TrackMergeTarget=false ??
    }

From the release management point of view this means the following: You create a release 1.0.0 branch and want to stabilize the release candidate to bring this one to production. So what happened if your product manager says to cancel the release and go back to the develop phase? The release candidate 1.0.0 has not been merged and tagged on master. But it will be properly merged to develop and deleted. Thus the next version on the develop branch is still the next version of the previous version (that means in my example the version 0.1.0).

Maybe it is a good idea to reuse this property and make the following change:

/// <summary>
/// Version is extracted from older commits' merge messages.
/// BaseVersionSource is the commit where the message was found.
/// Increments if PreventIncrementForMergedBranchVersion (from the branch config) is false.
/// </summary>
public class MergeMessageVersionStrategy : VersionStrategyBase
{
    private readonly ILog log;

    public MergeMessageVersionStrategy(ILog log, Lazy<GitVersionContext> versionContext) : base(versionContext) => this.log = log.NotNull();

    public override IEnumerable<BaseVersion> GetVersions()
    {
        if (Context.CurrentBranch.Commits == null || Context.CurrentCommit == null)
            return Enumerable.Empty<BaseVersion>();

        // new
        if (!Context.Configuration.TrackMergeTarget)
            return Enumerable.Empty<BaseVersion>();
        ...

[HHobeck]

I'm also thinking about it in which circumstances the MergeMessageVersionStrategy is used in the gitflow worflow. Cannot find any scenario. Maybe it is good for the github workflow with continues delivery?

[asbjornu]

The release candidate 1.0.0 has not been merged and tagged on master. But it will be properly merged to develop and deleted.

Why would a release/* branch be merged to develop but not to master? Shouldn't those merges be done at the same time and either both or none of the merges happen? I know there's no way to enforce that but socially, but still – that's how I understand the workings of Git Flow's release/* branches.

[asbjornu]

I'm also thinking about it in which circumstances the MergeMessageVersionStrategy is used in the gitflow worflow. Cannot find any scenario. Maybe it is good for the github workflow with continues delivery?

I would recommend against its use for any other workflow than trunk based development aka mode: Mainline.