Learn More
Resend Email
6
DBX12
4y

Todays "WTF Bitbucket?"

You can mark a PR with "Requesting changes" even if it was already merged but you haven't refreshed your page.

The whole PR page is loaded with a dozen independent requests but you cannot reload a single "widget" (e.g. Activity) without refreshing the page.
And then you do an API request "mark PR with request for changes" and the server accepts that, even if the PR is merged. Why? Nobody looks at a merged PR with Requested changes. You would expect a warning "cannot mark request changes, PR already merged" but no, Atlassian fucked up here again.

The new "PR experience" is shit. Just loading everything in a separate request does help nothing if I still have to reload the page to get an updated PR view.

rant

atlassian

pr-experience

bitbucket
Favorite
Ranter
Comments
  • 1
    4y
    What if I tell you, there are people who re-use the same tickets, branches and even PR’s? You may request changes to an closed PR and re-open the PR by pushing new changes to the source branch?

    Anyways, even if you don’t look at the closed PRs, you still should get emails about it.
  • 0
    4y
    @petergriffin You can reuse a merged PR? Branches yes, but PRs?

    Why would you even want that? After merging, the source branch and the destination branch don't differ until you push again. And then you should open a new PR, because the comments from the old are no longer valid (as the points they mention are no longer part of the diff)
  • 0
    4y
    You add new comments to the old, closed PR, requesting changes, e.g. regressions of an deployed version. Then, you make the changes, create a new PR and reference the old one as a follow-up PR. That way it is completely clear why the PR exists and not just what changed. Additionally, you can better understand what the project situation was in the past.

    Since there are situations when you may want to make changes related to an ticket, but the ticket itself inherently doesn’t require to be changed in order to track the code changes.
  • 0
    4y
    I don't think that is the intended functionality of "request changes". It's meant to block the merge until the person removes that "request changes" flag or the PR creator adds new commits.

    If the PR was approved in the past, you should not remove the approval now because things changed. Once merged, the PR is history which should not change.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment