Ability to disable pull requests auto-updating

Issue #9361 wontfix
Nathan Goldbaum created an issue

Recently we've noticed several old open PRs get updated without any human intervention.

This is not the best behavior given our development workflow, which is based around pull requesting from anonymous heads in a mercurial repository and does not use feature branches.

Worse, it appears that pull requests do not actually auto-update at all, instead all pending PRs get auto-updated when another pull request is merged.

For example, last night the following pull requests was merged:


This caused the following pull requests to be automatically updated:




In all three cases this was not the desired behavior.

I don't think it's a good idea to let pull requests be updated without some sort of manual confirmation from the PR issuer. I would appreciate a way to revert to the old behavior.

Comments (40)

  1. Britton Smith

    As the person who was responsible for the merger the first PR mentioned above, I can say that the auto-updating of the other PRs was definitely not desired behavior. Regardless of my opinion of auto-updating PRs, this is definitely a major bug.

    I also have to agree with @ngoldbaum that auto-updating PRs with no human confirmation is not something I would ever want. While it may make streamline things for some people, I think the larger effect is to take power away from users. Additionally, I have, on occasion, mistakenly pushed additional changes to a head with an open PR and this new feature effectively removes the safety net.

  2. Michael Frauenholtz staff

    Hi Nathan and Britton,

    I believe your pull requests were updated because the destination branch changed once the first pull request was merged. This appears to be our intended behavior.

    However, I understand that this behavior may not be ideal for some workflows, so I've added a ticket to our backlog to make auto-updating optional. We'll update this issue when we have more to share.

  3. Britton Smith

    Hi Michael,

    Thanks for getting back to us. The problem for us is PRs getting updated through actions of people that are not the issuers of the PR itself. We often have multiple PRs open at once to and from anonymous or only bookmarked heads. This may not be the best workflow, but it seems like this new feature will make things a bit chaotic for us. Anyway, thanks again for responding and please let @ngoldbaum or myself know if there is anything we can provide you with when the status of this issue changes.

  4. MattT

    Hi there, I've been seeing this as well. PRs that I've issued have been updated to different heads than my current line of development, they aren't following bookmarks, and on and on. I would really prefer to be able to update them myself rather than having someone else do this, or even worse, having a buggy or opaque system do it. Any help would be greatly appreciated!

  5. Tarik Guney

    I also think there should at least be a setting via which we can disable this feature. There could be certain cases in which people find this a really nice improvement, but so far I have not seen a good use case for it.

  6. Nathan Goldbaum reporter

    For what it's worth, the really buggy behavior described above seems to have been fixed. Pull requests issued from forks now auto-update as expected.

    That said, it would be very nice to have an option to turn off this behavior if that is not what is desired for a project's development workflow.

  7. Nathan Goldbaum reporter

    Here's another pull request that was corrupted due to the change in behavior: https://bitbucket.org/yt_analysis/yt/pull-request/895/fixing-ramses-density-and-mass-units/diff

    Now, for example, if I want to incorporate changes from a proposed PR into subsequent work, I cannot merge with the PR head and then push to my bitbucket fork, since that will auto-update the pull request. The only way to incoporate changes from proposed PRs is (in mercurial) with a graft or a transplant - duplicating the changesets needlessly.

  8. Chris Morgan

    Yeah, we've been having the same problem. We are pushing to branches with outstanding pull requests in order to fix some issues found during review or testing and everyone is incorrectly seeing that as a request to review the pull request again.

    An option to turn on/off this auto update would be helpful. Auto update is really messing us up here.

  9. Former user Account Deleted

    It causes a security issue, once the code can change unexpectedly after the review and before the merge.

    I think that the pull requests should be like a snapshot as the tags marks a specific point in the history or, for the use of commits, a branch with special name and special permissions for commits only of the reviewers.

  10. Radosław Antoniuk

    +1 for opting out from auto-updates of pull requests. I guess this could be a per-repository or per-user setting.
    Pull request by definition should contain a closed set of commits that can be reviewed by the reviewer. Otherwise reviewing doesn't make sense as in the moment of accepting the PR it could have already changed.
    Could you give us a status update on adding the switch to disable that automagical functionality?

  11. Joe Hart

    Is there a way to stop pull requests from being auto-updated yet? A minute ago, someone approved a pull request but it had not yet been merged. I opened the page to create a new pull request for a different block of code and saw that the original PR had not yet been merged, so I hit the back button so I could go look at the PR. To my surprise, my new changes were showing up and it was still showing that my co-worker had approved the request, even though there was new code now.

    This is a terrible feature. Please give us a way to opt out of it.

  12. Maarten Reijmerink

    +1 for opting out from auto-updates of pull requests. preferably on a per-pr-basis, as current functionality is also useful.

  13. Frank Spafford

    I also need the feature for opting out from auto-updates of pull requests. We typically make small changes in a pull request, and have the pull request associated with a specific JIRA task. I need control so that I do not mix updates for multiple JIRA items in a single pull request.

  14. Dimitar Sakarov

    Is it an option as well to be able to restrict further pushes to the branch (even if it looks stupid as well) in order to not reset the PR status and make it nearly impossible to finalize while different changes are pushed to the branch during the review?

  15. RomanChallenger

    The pull request auto-update is terrible. Totally screws up git flow for peer reviews. Please PLEASE add a way to disable this total mess.

  16. Josh Resnicow


    Another idea I had was to add an option to automatically make a new branch for each pull request. That way only changes to the new branch would update the pull request. Not sure if this would cause some additional issues with propagating the updates to other branches though, I'm still kind of new to Git.

  17. Saurabh Sahni

    I am also facing the same problem. We need a control to stop auto update of existing pull requests.

  18. Eddie Fletcher

    Any updates on this issue? Our team is just starting to get in to more formal processes around merging and it makes it very hard for our reviewers when maintainers keep working on their own branches, adding unstable code, after they indicated that at certain point in time, it was stable and ready to merge back.

    Edit: For now I have found a workaround, which is actually working well the auto-updating feature:

    I have asked our maintainers to open a new offshoot branch for each new Pull Request. This allows the PR to stay at a fixed point in time (on the offshoot) while they keep committing to their own branch without worrying about updating the Pull Request.

    The added benefit here is that with auto-updating, I can then go and perform any fixes needed before merging the PR from this separate branch, without interfering with anything they are doing on their main branch.

    Hope this helps someone else in the same situation.

    (Oops I've just noticed that this is what @compujosh said earlier on, it would be really nice if this was automatic)

  19. Max Hayward

    +1 for optional auto-updates on pull requests

    This was unexpected at first occurrance and goes against our current workflow. Regardless of how we decide to proceed, it would be nice to have the option of switching this behaviour off.

  20. Yuri Rodrigues (live2die.a.d)

    Does anyone know if the option to enable/disable auto-updating of PRs was added to Bitbucket Server 5.4 ?!
    I'm seeing that auto-updating is no longer working with this version .

    With a distributed repository like Git, I can't see how you can safely (i.e. in a non-conflicting way) get around not updating your source branch to be as close to the target as possible (which is usually "main") - if others have beaten you to merge in conflicting code, how are you going to resolve without another review ?!
    Yes, it can be a moving target, and the controls for that probably need to be out of the repository and in the SDP processes.

  21. Ernst de Haan

    For comparison: I've recently used GitLab (it was probably not the Enterprise edition), and while it also auto-updates PRs, it does indicate for every comment when this comment was given on an older version of the PR.

  22. Justin Yackoski

    This (along with the auto-deletion of comments during updates) makes the built-in pull request reviews almost unusable. This is also an issue if integrations are enabled. For example, if Code Collaborator has an update pushed every time a branch is updated, you'll end up with a TON of extra commits in the review. The normal dev cycle is push, push, push, squash, put into review, push, push, squash, push, squash, put into review again, so you can't trigger on a push or a squash, you need something else.

  23. Alastair Wilkes staff

    Hi everyone,

    Given the relative lack of discussion on this issue in recent years, and since the team is currently focused on higher priority items, I am closing this issue to indicate that we don't plan to address this in the near future.

    (FYI -- comments are not deleted when updates are pushed; they become outdated and can be viewed by clicking on the "(n) prior comments" button on a file's diff header)

    Bitbucket PM

  24. Robert Bartlett

    The lack of discussion, is because I believe that everyone know what needs
    to be done. There is nothing else that warrants discussion.

    A wontfix status makes me very sad.

  25. Justin Yackoski

    Closing it would seem to indicate that it will never be fixed rather than just that it isn’t top priority, let’s just say that then? It seems like the issue has been known and ignored for ~4 years, and now the rationale that it is not worth fixing is that it has been known for ~4 years. Disappointing, as it is still a major issue, and the suggestion of auto-making a PR branch is relatively straightforward.

  26. Bruno Nicoletti

    FYI, we’ve moved to github because of this issue not being addressed. Sadly having to drop HG for git.

  27. Enon Avital

    What Robert said. There isn’t any more discussion because there’s nothing to add to this [!important] request.

    I wonder if Alastair's comment was in itself an auto-updating pull request that could’ve used human intervention to make a proper decision here.

  28. Log in to comment