Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-5665

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

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      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?)

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

            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.

            Jonathan Glass added a comment - 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.

            legacy-bitbucket-user added a comment -

            Many thanks for fixing this, we suffered a lot.

            legacy-bitbucket-user added a comment - Many thanks for fixing this, we suffered a lot.

            evzijst added a comment -

            You're welcome. Apologies for having taken so long to address this.

            evzijst added a comment - You're welcome. Apologies for having taken so long to address this.

            Pi Delport added a comment -

            This is a nice surprise to wake up to; thanks for fixing this!

            Pi Delport added a comment - This is a nice surprise to wake up to; thanks for fixing this!

            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

            Nicolas Venegas (Inactive) added a comment - 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

            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.

            Steven Peters added a comment - 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.

            lexohansen added a comment -

            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).

            lexohansen added a comment - 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).

            There is good news from @jonmooring in BCLOUD-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.

            Pi Delport added a comment - There is good news from @jonmooring in BCLOUD-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.

            qraynaud added a comment -

            Any update on this? This really is a problem...

            qraynaud added a comment - Any update on this? This really is a problem...

            Lots of dangling heads can also cause problems with hg pull https://bitbucket.org/*/* as discussed in BCLOUD-8263. In resolving that issue, @jonmooring 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.

            Steven Peters added a comment - Lots of dangling heads can also cause problems with hg pull https://bitbucket.org/*/* as discussed in BCLOUD-8263 . In resolving that issue, @jonmooring 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.

              Unassigned Unassigned
              bffdbb239501 Pi Delport
              Votes:
              12 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: