Wouldn't this result in an ever-growing diff? You'd see everything that's gone into master since the branch last rebased/merged master as "changed". When I think about a branch, I want to see changes unique to it, not what's going on in the rest of the codebase.
Showing merge conflicts inline like that is pretty cool, though.
In Bitbucket's implementation you still only see the changes that are unique to your branch, but they're diff'd against the current tip of master rather than the merge base.
I've said this in another thread, but I feel it really needs repeating.
The diff that bitbucket is showing you is one that has not been tested. That is, the diff against the merge base shows what the requester did and tested. The diff against the current tip, shows what will be the result.
I fully agree that it is important to bear that in mind. But, this is all the more reason for the merge to be done by another party before committing/pushing.
Consider, if you send a pull request for the kernel, Linus will do a local merge, then test, then push. In all of these gui apps, the final merged code is just there. No last second "fails sanity test, so not really going to merge."
However, if per convention you state that a branch going under review must always be rebased to the latest commit of [your main branch], you will be reviewing all at once the code that will effectively be merged (by a simple fast-forward), and the code that the requester tested.
It seems to me that this is the safest method as, when you add an automated testing tool to the mix, it's pretty much guaranteed that you cannot break the main branch when merging a PR.
I think rebase is not advertised enough, but it's the _de facto_ solution to most of these kinds of problems.
Close. Under this convention, somebody has to do a final test before pushing the merge commit. It can be a simple sanity test, not a full blown integration test. But somewhere somebody at least did a compile check.
If it fails that test, then you push it back to the person doing the work saying so and they need to fix it.
In a GitHub project I've contributed to (dolphin-emu), a compile check for all supported platforms, plus a few tests, shows up next to the big merge button. So the "other party" doing the merge is a robot, and you can still click the button.
I haven't been a committer on any other large GitHub projects, so I'm not sure how common this is.
So, sadly, I don't contribute to really any github projects. This is a new feature to me and does go a long way to addressing my concern. Honestly, it may completely address it. Certainly sounds like it does.
True, but at least it shows you the actual result of applying the diff to the HEAD, as opposed to all other GUI tools that show you a diff that nobody has seen, let alone tested, in a merged state. So what is done by bitbucket is better in that regard.
Showing merge conflicts inline like that is pretty cool, though.