Close feature branches in pull requests *before* merging them for hg (BB-6927)

Issue #5665 resolved
Pi Delport
created an issue

The way Bitbucket pull requests currently handle branch closing, by merging first and then closing, works against the grain of Mercurial: it creates a dangling head for each branch-closing commit, which clutters the repository history, and frustrates features like hg pull -r <rev> (which won't pull in the closing commits relevant to the target revision).

For this reason, the usually recommended way of closing and merging branches in Mercurial is to close them before merging them: see e.g. here and here. This makes for a cleaner and more readable history, and avoids the usability problems above.

Can the branch closing feature for Mercurial repositories be changed to work this way?

(Alternatively, if there are users who for some reason insist on the current close-after-merge behavior, can both options be supported?)

Comments (17)

  1. Pi Delport reporter

    Do you have an indication of where this lies in the priority queue?

    The new PR and review functionality is fantastic, but this feature is critical for us to be able to use it effectively. At the moment, we have to manually close and merge each PR's branch, instead of using Bitbucket's web-based merge, which adds a lot of unnecessary friction and overhead to the process for our team. (The alternative of leaving dozens or hundreds of dangling close commits is not really an option for us.)

  2. Quentin Raynaud

    +1. I would REALLY like this too. I believe the way branch are closed right now is more the git way of doing this. But it is much cleaner on git because the whole branch is deleted. Much more the close branch option is not available across forks which is veryyy frustrating. I believe if the closing was done before the merge, then it would be imported by the merge and thus the branch would be properly closed on both sides.

    Right now because I often work on a fork of the master repository, when I close a branch it is never imported to the main repository who keeps a lot of useless branches visible for anyone. That's really a problem.

  3. Steven Peters

    Lots of dangling heads can also cause problems with hg pull*/* as discussed in #8263. In resolving that issue, @Jonathan Mooring said that we should be closing our branches before merging. I pointed out that bitbucket's web interface to pull requests don't work that way, but didn't get a response. I'm voting for this issue to be resolved.

  4. Pi Delport reporter

    There is good news from @Jonathan Mooring in #8263, earlier:

    You're absolutely right that pull requests close the branch after merging, which is incorrect (or at least ill-advised). [...] I've raised that issue with the team and we'll re-evaluate our process around merging Hg pull requests.

    It would be great to not have to still close and merge everything outside of Bitbucket, as we have to do now.

  5. Otto Hansen

    I would also like to see this.

    It creates awkward dangling heads and also has the counter-intuitive result of moving the tip bookmak to the closed branch rather than the working branch.

    For instance: I am working in featurebranch1, finish my project, and submit a pull request. The pull request is approved and the changes are merged into the default branch and featurebranch1 is closed.

    If I look at the commit history, the most recent commit is the branch close not the merge. The tip bookmark sits on featurebranch1. I understand what this means, but to someone who is new to version control, I could see them wondering why they aren't using the most recent changeset and trying to update to the closed branch (which will unclose it and continue development on the branch that shouldn't exist anymore).

  6. Steven Peters

    Despite complete radio silence from bitbucket developers, I think this may have just been fixed. With two recent pull requests, I've seen the branches close before merging.

    Whoever did this, thanks for fixing it.

  7. Nicolas Venegas

    Despite complete radio silence from bitbucket developers, I think this may have just been fixed. With two recent pull requests, I've seen the branches close before merging.

    Yes, it has been fixed. We were just waiting to see if any errors came in after we deployed the fix :)

  8. Jonathan Glass

    Btw, have just noticed that if the merge fails for whatever reason (i.e. I just got pre-empted by another merge which introduced conflicting changes), the merge fails and rolls back but the branch closure remains. This seems like a bug, i.e. if the branch can't be merged then the closure should be rolled back.

  9. Log in to comment