Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A better pull request

developer.atlassian.com

Post reply on HN
Print view View original

151–160 of 167 posts

Re: A better pull request

#151

Post by bri3d »

cataphract wrote: post #134
bri3d wrote: post #77

Earlier quoted context omitted.

But once you click the "Merge" button in GitHub, nobody has ever seen or tested the new state of master. I'd rather see the diff that's going to go into master (tested or not) than see a diff that effectively means nothing (as it will never be applied to anything).

That is not necessarily true. The test results (e.g. travis, but you can use for instance Jenkins for your Github repository) shown next to the merge button are the result of a merge between the pull request branch and the branch you want to merge into. That's why when you do an ls-remote, you will see something like: c3ca093c99495d0ddbb3197c14e0cdf514266392 refs/pull/2/head 0f5993828108bd2960713dc34a9ac7bef6dbc653 r…

That's how we build using Jenkins - it's a nice feature, but it doesn't retrigger when the target branch changes. So, while it's useful so far as that it's better than simply building the branch, it doesn't ensure that "what you tested is what you get."

Re: A better pull request

#152

Post by brazzledazzle »

sls wrote: post #119
Alupis wrote: post #109

Earlier quoted context omitted.

For a team, pricing is different. 50 repos is $100 a month, 125 repos is $200 a month ($2,400 a year). Granted, it's not "exponential", I was using a figure-of-speech referring to the pricing becoming significant. For an internal-dev team which generates a great deal of new repos throughout the year (one-off scripts/programs for different departments, etc...), this adds up very quickly. If you reach that 126th repo,…

GitHub Enterprise is an appliance VM you run internally. It's charged per seat. The last enterprise-y company I was at used it primarily because you keep your code inside the firewall, but also because the pricing model is more aligned with the usage in that environment, as you suggest.

GitHub Enterprise is pretty pricey. It's almost exclusively about being able to host internally.

Re: A better pull request

#154

Post by rubiquity »

cpeterso wrote: post #146
orbitur wrote: post #144

Earlier quoted context omitted.

Wow, the first thing I do when creating a new repo is disable fast-forwarding, especially for large teams. The merge commit is the quickest way to see all the changes that came in from a branch, and if you do branching right, all the changes related to a particular feature by one developer. Also, merge commits are much easier to roll back, no matter how rarely you need it.

Another option, used by large teams at Facebook, is to only use fast-forwarding but squashes all branch commits. You can still roll-back a merge, but your master's revision history is still linear (for what that's worth).

Yes this is what I advocate doing as well in my post above.

Re: A better pull request

#155

Post by Too »

Something that bugs me with almost every source control GUI is that there is usually no way to spawn a three way diff after a merge has been done. They might support three way merge on conflict but bang, once you save you can not get that view back. They also often don't understand that no branch was the master branch so if you diff the merged revision (diffing a single revision doesn't make sense yes but guis usually present it this way and diff it with the last revision) then you get all changes that has happened on master since the branch was created, wtf?? To see what only the branch contributed you have to manually select two revisions, diff them and then select the other revision and diff.

Re: A better pull request

#156

Post by latkin »

cpeterso wrote: post #146
orbitur wrote: post #144

Earlier quoted context omitted.

Wow, the first thing I do when creating a new repo is disable fast-forwarding, especially for large teams. The merge commit is the quickest way to see all the changes that came in from a branch, and if you do branching right, all the changes related to a particular feature by one developer. Also, merge commits are much easier to roll back, no matter how rarely you need it.

Another option, used by large teams at Facebook, is to only use fast-forwarding but squashes all branch commits. You can still roll-back a merge, but your master's revision history is still linear (for what that's worth).

This is how I prefer to handle PRs, too. `git merge --squash pr-branch`. Prevents the history from turning into an indecipherable tangle of branches, and prevents tons of "fixing typo," "code review feedback," "more code review feedback," "adding back file" kinds of commits from taking over the history.

We are on GH, it's quite annoying that they provide 0 support for rebase/squash style PR application. http://stackoverflow.com/q/27974175/1366219

Re: A better pull request

#157

Post by jschwartzi »

iopq wrote: post #70
mkinsella wrote: post #27

Earlier quoted context omitted.

Are there that many non-enterprise companies using Bitbucket over Github? Most startups and mid-sized companies I know use Github for private repo hosting.

Tons of startups that you don't even know about use Bitbucket for their free private repos. When you have a team of 1-5 people there is no reason to pay for Github.

Bitbucket also supports Mercurial, which I find to be more user-friendly than Git with all of the same features.

Re: A better pull request

#158

Post by thejosh »

melvinmt wrote: post #28
fenomas wrote: post #7

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/

I use bitbucket mainly to host all my private repos (unlimited free private repos) and use github for my public ones. I'm not sure what the tradeoffs are regarding features (so far I'm not missing anything on bitbucket) but it's still git so the core things are still the same.

Same, we use Stash locally due to latency, ($10/yr for our tiny team), then mirror to Bitbucket each commit automatically.

Re: A better pull request

#159

Post by juriansluiman »

sytse wrote: post #135

GitLab B.V. CEO here. The proposed diff is interesting and I love the way they explained the idea. During the development of GitLab (over 10.000 commits) we never experienced the problem that was mentioned. Maybe it is because our codebase contains many tests. One related idea that a GitLab user proposed is not testing the feature branch but testing the merge of the feature branch into master. This would require rete…

It is exactly what Travis CI does for auto-PR testing on Github: they pull in master (or whatever base) and fetch the feature branch. They create the commit themselves and test the result. That way, you always get the tests based on the merged result which gives far more insights than tests on your (local) feature branch.

Re: A better pull request

#160

Post by masklinn »

bri3d wrote: post #151
cataphract wrote: post #134

Earlier quoted context omitted.

That is not necessarily true. The test results (e.g. travis, but you can use for instance Jenkins for your Github repository) shown next to the merge button are the result of a merge between the pull request branch and the branch you want to merge into. That's why when you do an ls-remote, you will see something like: c3ca093c99495d0ddbb3197c14e0cdf514266392 refs/pull/2/head 0f5993828108bd2960713dc34a9ac7bef6dbc653 r…

That's how we build using Jenkins - it's a nice feature, but it doesn't retrigger when the target branch changes. So, while it's useful so far as that it's better than simply building the branch, it doesn't ensure that "what you tested is what you get."

In the Rust project, the merging itself is automated and the merge bot (bors) runs the test after having effected the merge. The merging is attempted after the branch has passed review.

That doesn't preclude running e.g. travis to get the branch's own status before the review happens.

Post reply on HN