Issue when merging master to a branch and then back to master using Mainline

[markryd]

When using Mainline after merging in a feature branch that has had master merged into it, GitVersion doesn't seem to correctly track the merge commits it should pay attention to.

See the snappily named VerifyMergingMasterToFeatureDoesNotCauseBranchCommitsToIncrementVersion test. When we create a feature branch, then merge master into it, then tag master and merge the feature branch in, we should only be at one merge commit past the tag, but FindMainlineModeVersion treats the merge from master to our branch as a merge into master, and commits before it as master commits.

I have a fix here that uses the FirstParentOnly flag on CommitFilter and make sure merges are to our target branch. I feel like I should be able to use that directly in the query for commitLog but that causes VerifySupportForwardMerge to fail, hence the dual queries shown.

[markryd]

After looking closer at the VerifySupportForwardfMerge test it doesn't work as I expected, perhaps I'm not understanding Mainline completely?

            fixture.MakeACommit("+semver: minor");
            fixture.AssertFullSemver(config, "1.1.0");
            fixture.MergeNoFF("support/1.0");
            fixture.AssertFullSemver(config, "1.1.2");

After this line I would expect the version to be 1.1.1? Master was at 1.1.0 and we merge in a single change. I didn't think it would matter how many commits were in the feature branch.

If this test is updated for that behavior, all tests pass just by changing the commitLog query in NextVersionCalculator to use FirstParentOnly.

[JakeGinnivan]

I think you are right.

A lot of mainline is pretty rushed, if it doesn't look like it makes sense then it may not :P I think it should be changed to 1.1.1 as you say.

[markryd]

Okay that simplifies the fix a bunch. Updated.

[JakeGinnivan]

Nice!