OpenUru.org

I couldn't help but notice D'Lanor's frustration with BitBucket today about merged pull requests. I remember rarified had the same trouble a while back. I don't know if there is a way to avoid this, or if BitBucket is trying to be too clever for its own good. But if anyone can explain this effect and how to avoid it (please - besides "use github"), that might be very helpful to everyone. We want to maintain one fix/feature per commit or pull request. Also, if it's a bug or misfeature, I can take the issue to BitBucket if explained well enough for them to understand.

This post is sufficiently vague that I honestly don't know what the problem is

10 days ago I created a pull request following this tutorial. Then yesterday I committed a fix for blank pages in the city book and wanted to create a new pull request for it. Following the same tutorial I compared the forks again and there was this big fat button that said "update pull request", just begging to be pressed... which I did, expecting a list from which to pick the latest revision. Instead it immediately merged all the differences into the old pull request.

What I "think" I should have done is first select the latest revision and then click on the not so very big blue arrow pointing to the left. The 101 tutorial does not explain this so it is bound to go wrong the first time when you are a Bitbucket newbie like me.

I'm not sure what that big fat button is supposed to do, but your second guess sounds like a better bet to me. In fact, now that I look at it, that is pretty much what you want to do--though I would recommend creating a named branch (these are technically in mercurial, but they make life easier on bitbucket it seems). Then, hit "branches," select the branch with your fixes, and then "<- send pull request". It works pretty much the same way on github, except we have the network graph to help us out even more.

Hoikas is on the right track with his advice, I think. The problem was that you committed the city book fix onto the same branch as previously the Er’cana elevator fix. You should have committed it on a separate branch, branching off from some revision that’s already in the upstream repository. For my cleaned-up version, I transplanted the fix into its own branch, choosing the latest upstream revision as the base. (I could also have chosen the same one as the Er’cana fix was based on.)

Apparently Bitbucket then noticed that there was already a pull request for the branch that you just committed on, and presented you with a big fat “update pull request” button. If you had been on a separate branch, that button wouldn’t have been there.

Note that one difference to GitHub is that there is no explicit “update pull request” button on GitHub, but pushing more commits onto the same branch automatically updates the pull request.

OK, so branching it is from now on. I never thought I would need that in my own repo since I am the only person committing to it and it seemed like a good idea to keep things simple.

You do all of your work in a branch, which then gets integrated into the master/head/default branch of the upstream repository. You should probably leave the master/head/default branch as a clean representation of the upstream to facilitate diversion on your end. I know on git, it can get very complicated and ugly if you do all of your work in master itself.

EDIT: I just had my own issues with bitbucket and pull requests. Mercurial is very frustrating when it comes to branching