Can't revert a declined pull-request action (BB-6192)

Issue #4954 open
Matthieu Perrot
created an issue

If someone of your team decline a pull request by mistake, you can't revert this operation even if your are the owner/manager of the repository with all admin rights. The alternative is to retry with a new pull-request, with the caveat of producing a spurious duplicate of the former pull-request.

In addition, it seems also strange that a pull request can be declined even if all participants have approved it !

Official response

  • Claire Bianchi staff

    We are currently working on improvements to Pull Requests. This work is ongoing and will include updates on how decline works today. At the moment we are considering adding states other than just Approve and Decline to remove the need to revert entirely.

    Please continue to follow this ticket for updates, and add comments describing any use-cases that are important to your team and not already covered above.



Comments (177)

  1. Dylan Etkin

    Hi Matthieu,

    I think you are correct that we should allow you to re-open a declined PR.

    I would hesitate to not allow you to decline just because folks have approved. We are aiming for a light-weight approval system and I think that would start to dicate workflow a bit too much.



  2. Christian Walther

    Seconding the wish for a possibility to reopen declined pull requests.

    I have a couple of pull requests that I have no idea how they ended up declined (the Activity tab shows no record of anyone declining them) (may have something to do with #4900), and I’d like to reopen them.

  3. Jon

    +11 for having a confirmation dialog if you try to decline a PR when one or more reviewers have approved it. Allow, but warn :) Ah... separate feature - I'll see if it exists and create a feature request if not.

    edit Issue #8346 created for this sidekick request

  4. Michael Bean

    I once removed a branch remotely and then pushed a new version, but a hook took that as a command to decline the PR. Just because it was empty for the 5 seconds I took between commands doesn't mean I wanted to decline it. I just wanted to swap out the code for the right code. (So if a branch is empty, it is still a valid PR...just with no diff to show.)

    Maybe this is another problem, but is related and was the main cause of accidental irreversible DECLINEs on PRs.

  5. David Meister

    Is this really a feature request or a massive bug in the system? This really needs to be fixed. It's been 2 years since this thread was opened (I'm willing to bet that Atlassian internally knew about this issue long before it was publicly reported) and there's still a largely undocumented button that FUBARs your PRs prominent in the UI.

  6. Michael Bean

    No idea...could the creator of this request please change it to a non-minor priority? I don't think it should be difficult at all to be able to flip a boolean in the database (declined/not).

  7. Michael Bean

    I agree. But the fix should be fairly intuitive.

    On a positive note, it looks like the decline button, even if accidentally hit will request the user to provide a reason to decline, which mitigates the possibility of accidentally pushing the button. I don't have much of a problem with the button itself. I have a problem with the fact that the PR was automatically declined when the branch was removed. Now that I know more about BB, I wonder if there was a hook involved. I'm going to look into that...

  8. Michael Bean

    Yeah, looks like there is a "hook" involved that can't be disabled. The PR realizes that there is nothing to commit and determines that that means "decline". Git can revert reverts, so it makes sense to be able to undo a decline. I vote for the ability to reverse a decline.

  9. Rick Cuddy

    +1 etc etc

    Really want a workflow based around declining because of problems that can and should be fixed, to replicate workflows such as Phabricator where approval indicates request can be merged, where decline indicates work remains to be done.

  10. Victor Engel

    +1 I also just declined a PR and can't reverse the decline. Not good. I declined because of a perceived problem. When the problem is resolved, the PR should be able to proceed.

  11. Anonymous

    This was first brought up as an issue 3 years ago. How long does it take Atlassian to implement features? Yes, don't dictate workflow, but also do not tie our hands. I have several comments to create tasks from a pull request that has already been declined. In not allowing us to re-open it, you've already dictated workflow.

  12. Tri Nguyen

    Please vote and not comment a "+1". You can also follow this issue by watching it. This will avoid spamming all existing watchers with the noise. Perhaps we should say this explicitly in the description of the issue.

  13. Tim Ahrens

    Try finding documentation on what the "Decline" button does?? Does it mean I declined to do the review because I don't have time, OR does it mean I think the code cannot be released without the corrections I have suggested?? A simple mouseover tool tip would go a long way to clarifying this. So, I am very reluctant to click it not knowing what will happen when I do click Decline. Can someone please tell me?

  14. Michael Bean

    @Tim Ahrens Currently it marks the pull request as declined. If I recall correctly it will ask you to fill in a reason why you are declining it. It is currently irreversible (hence this ticket). I only decline a branch if a ticket is going to be closed or if we want to totally restart the branch, but leave the ticket open. This happens if we find we went down the wrong path for a ticket, but for some reason want to keep a history of the first attempt. This is only necessary if the pull request has a lot of history on it. If it doesn't have comments, I'd suggest just replacing the branch with a new set of commits. (Be careful when replacing branches, though. Sometimes in the process of rebasing a branch the remote one is removed, which can automatically trigger the decline action.)

  15. John Schank

    Agreed, not know what it does is the worst. There is an approve button, so logically I assumed declined meant that I reviewed it, but did not approve. Which, BTW, would be a good button to have.

  16. Michael Bean

    If you don't approve, I think the idea is that you are using JIRA and therefore take a ticket out of review stage and put it back into "Dev" or something like that. If you have reviewed, the developer(s) know it because of the state change there and because you left a comment which has your name listed as the commenter. But having an official "Done reviewing this round" might be a good way to let the developer(s) know that you are done and it is basically ready for them--at least in relation to your comments. If there are multiple reviewers, it might still be in review.

  17. Michael Bean

    @Jayd Lawrence If Stash has this and BB doesn't, I think that would be a bug as one expects Stash and BB to only differ in features that set them apart. Is revert decline meant to be a differing feature?? I hope not. @Matthieu Perrot do you know? If so, you may want to refile this under bug rather than as proposal.

  18. Stephen Sykes

    OMG still not resolved? Just accidentally declined (not fully understanding Atlassian's workflow here - and decline seems to be usable as "not until issues are addressed" versus "NEVER"). Now we're stuck.

  19. Michael Bean

    @Dylan Etkin do you mean to say that a workflow that includes an 'un-decline' doesn't make sense? It happens in real life. Sometimes something is declined purely because of timing, but when the moment is right, is re-approved. That is how some technology works.

    Un-decline is a natural process, doesn't dictate workflow any more than the person choosing to push the button corresponding to it.

  20. Joshua Swanson

    @Michael Bean No, check it again - what he said was that an un-decline makes sense, but it doesn't make sense to prevent declining because someone has approved it - which I completely agree with.

    Still, the key point here is that it's been four years with no action on this... and we really need to see some!

  21. John Schank

    It’s actually worse than that. The buttons imply that you are declining your review. But you’re really rejecting the PR and once you do. You’re screwed. There is no way to say: “I’ve reviewed this, and I want to mark it as NOT approved”

  22. Jacek Kobus

    well we can force our interns to create new pr's for every fix they make and fail but that's just a plain cruelty. Lack of this feature is annoying for someone who has to work with bb everyday, so if there's nothing else left, we'll move somewhere else.

  23. Eelke Blok

    Personally I value a well-conducted usability test which is then used as input by a UX expert to come up with a good solution a lot more than what users say they need. No offence. We're all software developers, so we've all been there, right?

    The latest Bitbucket Server (aka Stash) has a concept where each reviewer can either mark a PR as approved or "needs work" (that is without actually declining the pull request). To me that seems a better approach (not to mention a lot friendlier) than outright declining the PR. If the same workflow would be introduced on, to me that would reduce this issue (not being able to re-open a declined pull request) to maybe a slight inconvenience that I could live with perfectly fine. Actually - and I might be going too far now - it even makes sense, in a way. With this "needs work" workflow in place, if the PR is actually declined instead of simply marked to need some additional work, that would indicate it will not be considered to be merged in the immediate future. Only from a usability/undo perspective does it make sense to allow it to be re-opened, then.

  24. obutterfieldN

    I submitted a PR, had a good flow of comments on it and a team member declined it in error.

    Given that Atlassian seems to be all about workflow and tooling, what would be their suggested way of smoothly getting back to the the point pre-decline, with all comments intact?

  25. Mike Gruen

    Why bother? Both are equally ignored. It's been "new" for nearly 4 years, been in and out of the top 10 most voted for issues (currently no. 11), and seemingly not too hard to fix.

    We've pretty much modified our workflow to use Tasks to indicate when a PR is not ready to go due to outstanding work which can sometimes result in very long-lived PRs. In cases where we really do want to abandon the work done to date, we will decline a PR and then, when a new PR is issued, have the new PR's summary link back to the original PR so that the reviewers can see the full history.

    With better filtering, sorting, and labeling functionality on the page that lists all open PRs, this wouldn't be as bad of a problem -- aside from the "oops, I declined this by accident" problem. If Declined is truly a dead-end state, then maybe not every reviewer should have permission to press the button.

  26. Rob de Bruin

    Finally ☺

    Verzonden: donderdag 21 juli 2016 0:44 Aan: Rob de Bruin Onderwerp: Re: [Bitbucket] Issue #4954: Can't revert a declined pull-request action (BB-6192) (site/master)


    Ben Echols commented on issue #4954:

    Can't revert a declined pull-request action (BB-6192)

    Eelke Blok, you're right on - we're focusing on how to improve the pull request workflow with options like Bitbucket Server's reviewer status so it's easy to indicate when something needs work, rather than completely declining it. I don't have a date for availability in Bitbucket Cloud, but it's on the roadmap.

    View this issue or add a comment by replying to this email.

    Unwatch this issue to stop receiving email updates.


  27. Deborah Speece

    +1 just declined my PR because I accidentally made a duplicate, but I declined it at the same moment my team approved it. Now I have to ask them to approve the other one.

    Today, this is how I see Bitbucket.


  28. Eugene S.

    I declined my pull request because I've overlooked a bug, so members will not approve it by mistake. Committed a fix and tried to find how to undecline it...found this page instead.

    FIX: The fastest way now is to checkout to a new branch from "declined and fixed branch"(git checkout -b newbranchname), push it and create new pull request.

    <cough> 3 <cough> years <cough> already <cough>...

  29. Ryan Grippeling

    I find this pretty sad. How hasn't this been picked up yet? It's a major part of any respectable company's workflow to work with PR's. It isn't functioning the way it should for the past four years. I'm forced to keep PR's with over two hundred comments on code style open right now because if I decline the PR, everyone's time will have been wasted.

    Please fix this.

  30. Jeff Horner


    Logically it doesn't make sense to have a PR declined if each participant has approved it, so this behaviour feels spurious. Being forced to re-raise a PR and losing history is crazy.

  31. Paul Wagland

    @Benjamin Echols Any news in the last nine months? We are in the middle of an evaluation, and this is exactly the sort of thing that keeps me from unequivocally saying we should go with Bitbucket. Small mistakes in workflow end up having big consequences, with no way to undo them?

  32. Qteeth

    @PaulWagland I think this thread should be the end of any evaluation. It indicates pretty much everything one may need to know about Bitbucket team and their professionalism. We have a very reasonably sized feature, 5 years of user requests, fake promises from the production team and total abandonment of customers after it.

  33. Keith Green


  34. Guy Mograbi

    Great news! This is exciting.
    My team just mentioned this again in the post mortem again.
    They listed it as top item to improve our PR process.

    Thank you so much for this update.

  35. John Schank

    What about this: 1. Rename the current 'Decline' button, to 'Withdraw Pull Request', the functionality stays the same 2. Create a new button 'Reject', which puts a red 'x' badge on the user's avatar - as opposed to the green 'check' that 'Approve' does

    That's it. I think that would solve 90% of the confusion and accidental declines on PRs

  36. Joseph Keller

    Since this still hasn't been implemented here's an option for implementation: Create a new button called Disapprove that is the opposite of Approve. This is just a visual element like Approve. Also, you could make it so Merge is disabled while a Reviewer disapproves of the PR.

    We don't really decline PR's anymore because the Decline button is such a final thing to do on a PR. We only use it when we realize a feature will need to be worked on more during a later sprint. Otherwise, the PR just stays open even if there are problems while the person is working on them.

  37. Matthew Dickinson

    I just declined a pull request mistakenly (due to poor button labels IMO) and could not find a way to re-open it. Searching for a solution brought me to this thread. It seems people have been having the same issue for 5 years and it's still not fixed! LOL

    Let's see if my vote make the difference :)

  38. Richard Campbell

    Meanwhile, the enhancements GitHub has been adding to their PR workflow have been Amazing. I still use Bit Bucket for the personal stuff, but GitHub for business stuff. That being said, they have stated that it is on the list, and depending on Atlassian's income they may only have so many developers to support BitBucket. One may say they have too many initiatives going on, but my job has me in the same boat, so I somewhat get it. That being said, I hope they follow through. I could have written a complete Bitbucket clone in the amount of time it has taken to address this. :) Maybe they should consider rewriting the thing in Rails ;)

  39. John Schank

    Earlier I posted a suggestion for how to implement this. I believe it would take 1 developer a couple days to implement. But I say that, knowing nothing about the state of their codebase. So perhaps their design is such, that my simple suggestion would be difficult. But that, too, says something.

  40. Richard Campbell

    I believe most of their stuff is written in Java. Everyone has their own opinions about various languages, my personal preference is Ruby (on Rails) due to the large amount of open source libraries people have contributed around it. It allows for rapid development of applications. Twitter was originally written in RoR I believe, and GitHub uses RoR. However, to each their own. Every language has it's strengths and weaknesses.

  41. Qteeth

    Maybe its time to move to GitHub? What is holding us here in particular? Their attitude towards their users is clear. TBH I can't seem to imagine a worse example of it.

  42. Gunter Grodotzki

    I suppose for most of us, the only ones holding us here is "upper management". There are those who like Bitbucket, and there are others, who actually implement proper agile + ci/cd standards...

    Looking through many tickets it seems Atlassian is cought up with trying to "innovate" (build pipelines, dockerisation, etc.) when maybe, they should think of making their core product (scm) usable first..

  43. Gianluca Massera

    Honestly, I moved to GitLab. GitHub is better if you compare SCM, but there are things integrated with BitBucket as you mentioned ... and GitLab has many things including docker registry that it's really important for us.

    I agree that how Atlasssian is managing (IGNORE) this request for years is a master example of how not to deal with your clients :-D

  44. Qteeth

    Fun thing is that they don't ignore it. Recently (a year or two ago) someone from their team jumped in here and made some bold promises. But then disappeared completely :))

  45. Claire Bianchi staff

    We are currently working on improvements to Pull Requests. This work is ongoing and will include updates on how decline works today. At the moment we are considering adding states other than just Approve and Decline to remove the need to revert entirely.

    Please continue to follow this ticket for updates, and add comments describing any use-cases that are important to your team and not already covered above.



  46. Alastair Wilkes staff

    Another update -

    We're continuing to work on the new pull request UI, which should be available for you to test soon.

    This feature is not yet included - we are focused on improving other areas of the PR experience - but it may in the future.


  47. Vernon Cole

    Considering the recent sale of BitBuckete's competition to Evil Incarnate, Inc, it would be a really good idea to fix everything possible as fast as possible. There are going to be some people looking around for an alternative.

  48. David Zemon

    That's a nice idea Vernon, but just because GitHub got sold doesn't mean Atlassian suddenly has four times as many developers. They can shift some personnel around, but I wouldn't get your hopes up for any drastic change.

  49. Log in to comment