Detect and handle rebasing and auto-merge in more situations (BB-7937)

Issue #6768 open
Marcus Bertrand
staff created an issue

Bitbucket attempts to auto-merge pull requests that were merged locally via a rebase. It would be great if Bitbucket could detect more unique workflows and situations where rebasing may cause the pull request to lose track of the commits or branches. Or detect when a user has rebased and merged, then removed the branch that the pull request was the source/destination of.

Comments (7)

  1. Matt Broadstone

    I think this is what I'm looking for as well. My team all maintain a fork of the master project which only I have access to, and we use the pull requests to indicate that a feature is complete and should be merged in. After the relevant parties have approved the pull request, I then go to my local master checkout and "git pull --rebase <fork> <branch>" followed by a "git rebase master" (if needed) and pull the changes in that way. Unfortunately, this leaves us with a bunch of empty pull requests. For the meantime, I've been declining them with a message "rebase merged," but it would be great if we could capture that what really happened is that the pull request was merged in, just not with merge + an extra merge message

  2. Garrett D'Amore

    Want to add my concurrence here as well! I'd be happy to have an "Integrated" button or somesuch that indicated that the changeset was integrated in a way that the webui can't detect. Could even include the changeset ID if that helped. :-)

  3. Oleg Oshmyan

    I got this pull request, and I pushed the commits to my repository directly. I was pretty sure this was supposed to automatically close the request, but nothing happened to it whatsoever. Why? And could an admin mark that PR as merged manually now?

  4. Log in to comment