[legomaster]

It seems like the example of double fixing the calculation is a great reminder of the value of unit tests. Even if both commits added a unit test in slightly different ways so they didn't conflict, you'd just end up with a failing build and know something got screwed up.

[Revell]

But still the test would only fail after the merge, whereas you'd want to catch this before.

[jbrooksuk]

On GitHub you can have tests run before you've merged, so you know whether it's safe or not.

[russell_h]

Don't the tests just run on the branch before the merge? If so, you wouldn't actually see the failure until after you merge.

[masklinn]

> Don't the tests just run on the branch before the merge?

The merge button is only green if github could generate a merge commit, and that merge commit is made available. You can run your tests on either the branch before merge or the branch after merge, as you prefer.

You may want to do both and have the former block the latter: the merged head is going to change (and require a re-test) any time the target branch gets a new commit, no point in wasting cycle if the branch's own tests don't pass in the first place.

[caust1c]

You can do either. Or both if you really want.

    $ git ls-remote
    From https://github.com/cyaninc/git-fat.git
    4c86c39bb5fca55a692d11680ed62fd5cb183921	refs/pull/14/head
    cb850f9d0bd09f8bb903e1c5959cef24ceb51695	refs/pull/14/merge

The merge ref is what the code would be if you merged it.

[alexsop2]

I'm guessing this is because a merge commit is created before the merge is fully executed.

[GolfyMcG]

Yeah - we run both the pull request and the master + branch merge every time.

[longlivegnu]

Can't you run unit tests before you merge on an Atlassian service too?

[jbrooksuk]

I'm not sure about BitBucket as I don't use it, but I expect so.

[legomaster]

You can, though you doing get to do it by using the ref/pull/## trick. That's just a connivence, you can get CI to do about anything.

[Revell]

Fair point!