5 ms·

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 di

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 12y ago
But still the test would only fail after the merge, whereas you'd want to catch this before.
- jbrooksuk 12y ago
  On GitHub you can have tests run before you've merged, so you know whether it's safe or not.
  - Revell 12y ago
    Fair point!
  - longlivegnu 12y ago
    Can't you run unit tests before you merge on an Atlassian service too?
    - jbrooksuk 12y ago
      I'm not sure about BitBucket as I don't use it, but I expect so.
    - legomaster 12y ago
      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.
  - deleted 12y ago
    [deleted]
  - GolfyMcG 12y ago
    Yeah - we run both the pull request and the master + branch merge every time.
  - GolfyMcG 12y ago
    Yeah - we run both the pull request and the master + branch merge every time.
  - russell_h 12y ago
    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.
    - caust1c 12y ago
      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.
    - masklinn 12y ago
      > 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.
  - alexsop2 12y ago
    I'm guessing this is because a merge commit is created before the merge is fully executed.

Revell 12y ago

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

jbrooksuk 12y ago
On GitHub you can have tests run before you've merged, so you know whether it's safe or not.
- Revell 12y ago
  Fair point!
- longlivegnu 12y ago
  Can't you run unit tests before you merge on an Atlassian service too?
  - jbrooksuk 12y ago
    I'm not sure about BitBucket as I don't use it, but I expect so.
  - legomaster 12y ago
    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.
- deleted 12y ago
  [deleted]
- GolfyMcG 12y ago
  Yeah - we run both the pull request and the master + branch merge every time.
- GolfyMcG 12y ago
  Yeah - we run both the pull request and the master + branch merge every time.
- russell_h 12y ago
  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.
  - caust1c 12y ago
    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.
  - masklinn 12y ago
    > 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.
- alexsop2 12y ago
  I'm guessing this is because a merge commit is created before the merge is fully executed.