Commit count resets to 0 when merge detected on branches

[msnelling]

We have a case where developer A committed his changes before pulling down changes previously pushed by another developer B, he then has to pull B's changes down, merging them, before he's allowed to push his own changes. This case seems to reset the commit count to zero at the point developer A's changes are merged.

[gep13]

Interesting. What happens if you rebase the changes rather than merge, or is that not an option?

Sent from my Windows Phone

---

From: Mark Snellingmailto:notifications@github.com
Sent: ‎19/‎10/‎2015 16:58
To: GitTools/GitVersionmailto:GitVersion@noreply.github.com
Subject: [GitVersion] Commit count resets to 0 when merge detected on branches (#700)

We have a case where developer A committed his changes before pulling down changes previously pushed by another developer B, he then has to pull B's changes down, merging them, before he's allowed to push his own changes. This case seems to reset the commit count to zero at the point developer A's changes are merged.

---

Reply to this email directly or view it on GitHub:
#700

[msnelling]

Hi Gary, Unfortunately rebasing isn't an option for us. 

[orjan]

Hi Mark! Are you pulling from develop or master?
On Oct 19, 2015 6:23 PM, "Mark Snelling" notifications@github.com wrote:

Hi Gary, Unfortunately rebasing isn't an option for us.

On Mon, Oct 19, 2015 at 9:14 AM -0700, "Gary Ewan Park" <
notifications@github.com> wrote:

Interesting. What happens if you rebase the changes rather than merge, or
is that not an option?

Sent from my Windows Phone

---

From: Mark Snellingmailto:notifications@github.com

Sent: ‎19/‎10/‎2015 16:58

To: GitTools/GitVersionmailto:GitVersion@noreply.github.com

Subject: [GitVersion] Commit count resets to 0 when merge detected on
branches (#700)

We have a case where developer A committed his changes before pulling down
changes previously pushed by another developer B, he then has to pull B's
changes down, merging them, before he's allowed to push his own changes.
This case seems to reset the commit count to zero at the point developer
A's changes are merged.

---

Reply to this email directly or view it on GitHub:

#700

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#700 (comment)
.

[msnelling]

Actually we're pulling from a feature branch (using GitFlow).

[orjan]

Just to make sure that I understand the flow.

If I understand correctly you're having 4 branches. Master, develop, feature/epic, feature/epic-part1 where feature/epic is merged into feature/epic-part1? And you're expecting to track the develop branch?

On 19 Oct 2015, at 18:52, Mark Snelling notifications@github.com wrote:

Actually we're pulling from a feature branch (using GitFlow).

On Mon, Oct 19, 2015 at 9:49 AM -0700, "Örjan Sjöholm" notifications@github.com wrote:

Hi Mark! Are you pulling from develop or master?

On Oct 19, 2015 6:23 PM, "Mark Snelling" notifications@github.com wrote:

Hi Gary, Unfortunately rebasing isn't an option for us.

On Mon, Oct 19, 2015 at 9:14 AM -0700, "Gary Ewan Park" <

notifications@github.com> wrote:

Interesting. What happens if you rebase the changes rather than merge, or

is that not an option?

Sent from my Windows Phone

---

From: Mark Snellingmailto:notifications@github.com

Sent: ‎19/‎10/‎2015 16:58

To: GitTools/GitVersionmailto:GitVersion@noreply.github.com

Subject: [GitVersion] Commit count resets to 0 when merge detected on

branches (#700)

We have a case where developer A committed his changes before pulling down

changes previously pushed by another developer B, he then has to pull B's

changes down, merging them, before he's allowed to push his own changes.

This case seems to reset the commit count to zero at the point developer

A's changes are merged.

---

Reply to this email directly or view it on GitHub:

#700

—

Reply to this email directly or view it on GitHub.

—

Reply to this email directly or view it on GitHub

#700 (comment)

.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[orjan]

Hi @msnelling I've tried to reproduce your issue with a test case but from my point of view it's looking ok, but I'll guess it's just me that doesn't understand your workflow?

Would you mind having a look at this commit?
orjan@eab0609

[msnelling]

Hi @orjan, Not that's not quite what I meant. We have three branches, master, develop and release/1.2.0.

The problem is when two developers are working on release/1.2.0. dev-A and dev-B are both on the same commit, then dev-B commits a change locally and pushes up to the remote, then dev-A commits a change locally and then also tries to push. dev-A's push is rejected because the remote is ahead so dev-A has to pull. This pull creates a merge point on the branch and it is at this point the commit count seems to be reset to zero.

[asbjornu]

@msnelling I think you've explained the scenario well now, but at least for future reference and perhaps also as a great illustration, I'd recommend drawing the sequence leading up to the problem you're seeing. It has proven to be quite helpful in similar discussions about GitVersion in the past.

[msnelling]

Ok, I think I've created a test which reflects the use case

[Test]
public void MergeOnReleaseBranchShouldNotResetCount()
{
    using (var fixture = new EmptyRepositoryFixture(new Config
    {
        AssemblyVersioningScheme = AssemblyVersioningScheme.MajorMinorPatchTag,
        VersioningMode = VersioningMode.ContinuousDeployment,
    }))
    {
        const string TaggedVersion = "1.0.3";
        fixture.Repository.MakeATaggedCommit(TaggedVersion);
        fixture.Repository.CreateBranch("develop");
        fixture.Repository.Checkout("develop");
        fixture.Repository.MakeACommit();

        fixture.Repository.CreateBranch("release/2.0.0");

        fixture.Repository.CreateBranch("release/2.0.0-xxx");
        fixture.Repository.Checkout("release/2.0.0-xxx");
        fixture.Repository.MakeACommit();
        fixture.AssertFullSemver("2.0.0-beta.1");

        fixture.Repository.Checkout("release/2.0.0");
        fixture.Repository.MakeACommit();
        fixture.AssertFullSemver("2.0.0-beta.1");

        fixture.Repository.MergeNoFF("release/2.0.0-xxx");
        fixture.AssertFullSemver("2.0.0-beta.2");
    }
}

I have also created a GitHub repo that demonstrates the conditions. https://github.com/msnelling/GitVersionTest/tree/release/2.0.0 should point to the head of the release branch that shows the version as 2.0.0-beta.0

[tpluscode]

👍

We're seeing the same behaviour. When release branch i merged to back develop, its counter resets to 0

[Tungsten78]

👍

I can confirm this behavior as well. Similar to @tpluscode, our team is merging an in progress release branch into develop to apply some fixes for in progress next release work (off of develop). GitFlow shows this as "bugfixes from rel. branch".

Inspecting the code, LibGitExtensions.FindCommitBranchWasBranchedFrom is relying on the most recent merge base. Unfortunately, this is not necessarily equivalent to where the branch was branched from. Maybe someone has a better way of finding the branch point - the only sure way I know of is to reverse iterate git show-branch --more=XXX develop release/1.2.3 and look for the commit previous to the first divergence point. The problem is choosing a value for XXX. There has to be a better way?

Also of note:

• Bugfix merges as described above ends up prematurely bumping the Develop version since it sees interprets the canned merge commit comment in its MergeMessageStrategy.
• Fairly sure this resetting also happens when forward integrating develop into a feature branch (by way of merge instead of rebase).

[Tungsten78]

Found a unit test trying to cover this scenario, however the problem was that the reset doesn't happen until the next commit.

I've amended it and it now fails: unit test.

I also added an AssertSemVer to show the premature version bump on develop. Not sure how people feel about this, I see discussions (#695) about bumping it when the release branch shows up.

[JakeGinnivan]

@Tungsten78 not sure how to fix the first one:

//!! develop bumped prematurely - we weren't done the release yet
fixture.AssertFullSemver("2.1.0-unstable.0");  //was 1.1.0-unstable.1 before the merge

I think going the way of #695 is the way to go, if you need to continue working on 1.1.x then take a support/1.1.0 branch and use that?