-
Suggestion
-
Resolution: Fixed
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?)
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.