A better pull request

#1

Post by kannonboy » Thu, Jan 22, 2015, 2:55 PM UTC

A better pull request
developer.atlassian.com

Re: A better pull request

#2

Post by legomaster » Thu, Jan 22, 2015, 3:00 PM UTC

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.

Re: A better pull request

#3

Post by brodney » Thu, Jan 22, 2015, 3:31 PM UTC

I really like the idea of merge conflicts being resolved in the open in a pull request, instead of the pull requester working in seclusion. For those of us with projects on GitHub, is there any way to replicate this behavior there?

Re: A better pull request

#4

Post by Revell » Thu, Jan 22, 2015, 3:41 PM UTC

legomaster wrote: post #2

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.

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

Re: A better pull request

#5

Post by jbrooksuk » Thu, Jan 22, 2015, 3:42 PM UTC

Revell wrote: post #4

legomaster wrote: post #2

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.

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

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

Re: A better pull request

#6

Post by Revell » Thu, Jan 22, 2015, 3:44 PM UTC

jbrooksuk wrote: post #5

Revell wrote: post #4

Earlier quoted context omitted.

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

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

Fair point!

Re: A better pull request

#7

Post by fenomas » Thu, Jan 22, 2015, 3:45 PM UTC

Seems quite sensible. This, some commentary on forking[1] I ran across the other day, and the way SourceTree is miles beyond github's client, all make me suspect I should be at least trying out bitbucket. But since literally everything I collaborate with is on github, I've not gotten around to it. Am I missing out, or does bitbucket have its own weak spots?

[1] http://zbowling.github.io/blog/2011/11/25/github/

Re: A better pull request

#8

Post by longlivegnu » Thu, Jan 22, 2015, 3:47 PM UTC

jbrooksuk wrote: post #5

Revell wrote: post #4

Earlier quoted context omitted.

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

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

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

Re: A better pull request

#9

Post by [deleted] » Thu, Jan 22, 2015, 3:49 PM UTC

jbrooksuk wrote: post #5

Revell wrote: post #4

Earlier quoted context omitted.

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

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

[deleted]

Re: A better pull request

#10

Post by jbrooksuk » Thu, Jan 22, 2015, 3:56 PM UTC

longlivegnu wrote: post #8

jbrooksuk wrote: post #5

Earlier quoted context omitted.

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

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

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