Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Try out the new Bitbucket Cloud pull request experience today!


Greetings Bitbucket Cloud community,

I am thrilled to share exciting news about how we're making code review easier in Bitbucket Cloud!

Code review is a critical part of the development workflow. To help reviewers assess changes quickly, we’ve historically taken a “code first” design approach for the pull request view, always displaying the diff first when the page loads.

Today, I'm excited to announce the new pull request experience, a redesign of the pull request view that displays everything the reviewer needs on a single page, without tabs. This new design helps reviewers approve changes faster compared to the old UI with features like:

  • An expandable sidebar containing file tree, build statuses, and other info
  • An omnipresent file tree for quick navigation between files without scrolling to the top
  • "Sticky" header for quick actions without scrolling back to the top
  • "Sticky" file headers so you always know which file you're reviewing
  • File highlights in the file tree as you scroll down the page so you always know which file you're reviewing
  • Collapsible diffs to mark your place as you review a diff
  • and much more

Learn more about these features at the Bitbucket blog.

To try out the new pull request experience:

  1. Click your avatar in the Bitbucket sidebar
  2. Select Bitbucket Labs
  3. Enable the New pull request experience feature

This opt-in release is a beta, and we are still working to bring some existing features over to the new view. We’ve made it easy to temporarily switch back to the old view using the “temporarily disable the new UI” link in the Feedback card at the bottom of the sidebar.

We'd love for you to try out the new experience and let us know what you think, either here in the comments or via the Feedback button in the new UI.

Happy reviewing!

Bitbucket PM


Looking good so far!

Can there be a setting to enable 'Side-by-side' view for all diffs for all Pull Request by default?

There a long-standing request of similar nature:

Like # people like this

Hi Maxim,

Thanks for the feedback! That feature is in the backlog for the new view.




Any updates on this issue?


Gavriil Tzortzakis

Like Deleted user likes this

Hi Gavriil,

Right now, we're working on adding back existing features and improving performance, so we haven't added this new feature yet. But it is planned!


Like Deleted user likes this

That's great to hear!

The only thing keeping me from converting over is the lack of task support. Our workflow uses them to block merges if there are dependencies. Keep up the good work.

Like # people like this

@Marco Bradley  Can you please describe your workflow? (Purely for my knowledge).

I described mine here

Just trying to understand if we can do things better.

Hi Srirang,

Ours is pretty similar to yours I have slack integration but less verbose, on PR merges and requests pop up to let the team know to review. One difference is that we use tasks to halt a request from being merged before a dependency or issue is resolved.

I tried to just let comments hold it up but in some cases there is another repo for the DB that would need to be checked in first before the code or vice versa. To help with that I utilize the tasks and set a PR from merging without all of them being addressed from the repo settings. 

It has greatly reduced mistakes and missed fixes due to an update masking a comment on a previous commit.

Like # people like this

Hi @Alastair Wilkes,

Our team is currently evaluating BitBucket Cloud, and the biggest unhappiness blocking acceptance here is not only the lack of side-by-side diff as a default or first-class choice, or even for a full-page switch, but that when the choice is made it doesn't even survive a single page refresh, let alone a session.

I appreciate the work your team has put into this, and I'm happy to hear this has been in the backlog since September, but has this yet even been moved from backlog into WIP? Is there any sort of expectation when this will be corrected or introduced?

Like # people like this

Sorry @[deleted], I missed your comment.

We recently added the capability to activate side-by-side mode for all diffs in a PR via the toggle in the diff action menu ("..." on the right side), but the state is not maintained. That is a great idea -- we already maintain expanded/collapsed state, so we should be able to add that in.

We realize that side-by-side mode is the preferred mode for many users, so improving the UX when using this mode is a priority.

Like Juris Sudmalis likes this

Kinda big regression for me: renamed / moved files are not detected anymore.

Like # people like this

Oops, just saw  the

we are still working to bring some existing features over to the new view

Which includes this .. :D

I know this comment is from a while ago, but in the interest of completeness, I want to mention that renamed/moved files are now shown properly in the new UI.


Bitbucket PM

Like Juris Sudmalis likes this
Deleted user Jan 09, 2020

@Alastair Wilkes Our team is still seeing this issue. When a file is renamed or moved, it is shown as if the old file was deleted and a new one created.

Like # people like this

Looks great so far ! 

Do you have any plan to implement Pull Request Tasks in the design ? 

ah I just saw the what's missing section in the article.


Thank you and looking forward for more features 

Like Cristina Escalante likes this

Sure thing!

As i understand this is just for the Bitbucket Cloud. Any plans to bring it to Bitbucket Server too?

Like # people like this

Nevermind, inline diffing is a WIP.

(Didn't found how to remove this comment.)

Looks great Atlassian Team!

I actually extended a plugin for my team that did a lot of these things like the sticky header and the collapsable files.

One of the main features my plugin does that would be a great additional feature here is allow you to collapse all files by the file type.

So for example, we have a lot of .test.snapshot files, which we don't always care to review, so you click a dropdown and select "Mark all .test.snapshot files as complete" and this will collapse all the snapshot files.

Thanks for the suggestion!

One of the features they are working on is making it so you can view comments even after a pull request is updated.  For now a good workaround is to make a synopsis of all the comments at the top of the pull request.

Like Ed Lomonaco likes this

Good news! This feature is now available. Click the "(N) prior comments" button at the top of each diff to view comments on lines that have been edited since the comment was made.

Awesome.  My team is using the new pull request feature and loving it.  Thanks for keep us updated on new developments.

Glad you like it!

The "prior comments" button is obviously a step in the good direction, but it falls short quickly; you can read past comments, but without any sort of code context it can be very difficult to understand what the comment is about, especially if you didn't write it and you're trying to catch up on teammates progress. The Activity view is helpeful here, but I find myself juggling between Activity/Diff/Commits way too often just to see what kind of update was done to the code VS my comments.

Ideally, past comments should be able to show a diff: the code as it was when the comment was written VS the code as it stands now. A bonus would be to add a "past comment" icon in the left gutter section (where you can click the line numbers) in a different color so you know there were comments on that part in the code, and that you can click to quickly see what the comment was and how it was updated.

Thanks for the additional feedback, Jonathan! We do plan to implement the code context (diff) in the new UI like it was in the old UI.

I like the idea of adding a button in the gutter. Deciding exactly which line that button should go on, however, is a bit tricky, since the line contents could have totally changed or moved around in the file, potentially making the comment irrelevant or confusing. After all, that issue is why comments are marked as outdated in the first place :)

Regardless of the solution, we'd definitely like to keep improving this part of the workflow because tracking comments and changes is critical to the code review process. Thanks!

Quick update: code context on outdated comments was added a little while ago. Thanks!

Wow, this is fantastic! Is there a plan to make a convenient Collapse/Expand All feature?

Glad you like it!

Yes, we plan to add that feature soon.

FYI, this feature is now available! Click the "three dot" menu on any file diff to reveal this option.

Deleted user Oct 01, 2018

BUG: Can't view older comments on file (clicking "1 prior comment" toggles file collapsing instead)

Deleted user Oct 01, 2018

I'm seeing this issue too.

The ability to view prior comments will be shipping very soon. Stay tuned!

This feature is now available. Thanks!

Like J likes this
Deleted user Oct 01, 2018

Any plan to make a similar view for the page when you're viewing a commit? It would be nice to have a unified theme like this all across Bitbucket.

Yes; over time you will see more Bitbucket pages adopt a similar design.

The resize panel containing the file tree is slow to respond. There have been a number of times where I have over-shot with the mouse and (because the cursor didn't change shape in time) I clicked on the divider between the two sections. A second-or-so later, the panel registers the click and slowly collapses.

Sometimes I am sent very large pull requests which can take a long time to review. Is there any way of recording the files which have been reviewed (or even those which have been viewed)? This would be a lovely feature.

Thanks for the feedback, Mike!

You're right - interaction performance isn't where we want it to be yet, and we're working on it at the moment. I'm curious if using the ] keyboard shortcut is more performant for you?

Ability to know which files have been (re)viewed would be good. We have received similar feedback from several other customers, so we're definitely considering that. Thanks!

I would like to add my voice to being able to mark individual files are reviewed. This is an immensely helpful feature. It is something that GitHub has, and there are browser addons for the classic PR experience in BitBucket (look for "BitBucket PR Review Helper"). This needs to be built-in for competitive parity.

Like Tyler T likes this
Tyler T Atlassian Team Mar 22, 2021

@James Brantly , work is starting on this soon. Please follow the public ticket to track the progress:

Is it somehow possible to use this without the wysiwyg editor? I have the wysiwyg editor turned off, but that setting seems to be ignored when I enable the new pull request feature.

(I like the new PR, but if it forces me to use the wysiwyg editor instead of markdown, I don't want it).

Like # people like this

Hi Jiri,

Thanks for the feedback. The new editor is the only option for the new experience. We'll update the "Atlassian Editor" feature description to mention this.

Ok, I see. It would be even better if you made the wysiwyg editor optional. Unlike markdown, it is really cumbersome to use.  For example, I did not figure out how to insert inline code in this window (not code block). In markdown it is a simple `xyz`.

Like Philip Brown likes this

Thanks for the feedback. FYI, the new editor supports almost all Markdown (including `xyz` for inline code).

@Alastair Wilkes have you actually gotten any good feedback from users preferring the "Atlassian Editor" over the simple, plain-text markdown editor for pull-request comments?

I'm genuinely curious as to why you're pushing it so hard. There's not a single developer at our company that has a nice thing to say about the new editor.

Like # people like this

I'm curious about that as well. Pull requests are mostly used by technical people (essentially developers though I guess other people might use them too, except it makes sense mostly for code, even if it's documentation as code).

And developers seem to me to be a population you do not want a wysiwyg editor for, and which should not have any problem with markdown.

The wysiwyg infuriates me as well. I could understand on jira or for the issued part on bitbucket considering it's used more by non technical people (but even then I really hate it), but for pull requests it really is for me an anti-feature. 

Like Philip Brown likes this

- The editor is incredibly buggy, but I hope that will improve.

- supporting markdown is not as good as it was in the old editor - e.g. if you paste abc` (without the ` at the beginning) and then correct it by adding it, nothing happens (this can easily happen when copying snippets from slack, for example)

But what really baffles me: in an editor for reviewing code, the toolbar contains emojis directly, but for code formatting, I have to go into embedded menus

Like # people like this

As long as we are discussing the editor, I thought it'd be worthwhile to link to the issue that has been declared on bitbucket in hope of being able to keep being able to use the old markdown editor:

This issue has unfortunately been closed as “won't fix” so far; let's hope this change or we get an editor that is actually properly usable by technical people instead of only be usable by “button clickers”.

Like chtz likes this

Hi y'all,

Thanks for the comments. It's clear that this is an important topic, and please know that we are listening and read every comment.

As to why we're invested in the new editor experience, the "what has changed and why?" section here is a good primer on that. In particular, we're excited about enabling rich content features that simply can't be supported by basic Markdown.

To answer the direct question -- yes, we have received lots of positive feedback about the new editor! :) That said, it is clear based on feedback like this that we can still improve the experience specifically for developers.

While the new editor already supports lots of keyboard shortcuts and Markdown shortcuts (including `inline code` and ```code blocks```) based on the comments here and on the public issue, it's clear that those are not as discoverable or usable as they need to be. And we definitely need to put the code-specific items in the toolbar (thanks for the tip, @Jiri Hana)!

As a reminder, you can view the available keyboard shortcuts by hitting ctrl/command + / or clicking on the "?" icon in the editor toolbar.

While we don't plan to support the previous Markdown-only editor in the new pull request experience, we are committed to making the new editor a great experience for developers who are used to writing Markdown every day. The best way to help us to do that is to continue providing editor-specific feedback through the Feedback button in the editor toolbar itself. We appreciate every feedback submission and bug report.

Thank you!


@Alastair Wilkes is that feedback from developers writing comments in Bitbucket pull requests or from across the whole Atlassian suite (Jira, Confluence, etc)?

I ask as I see the use case for Bitbucket as very different to the rest.

I would love to see some statistics if you had them

Yes, that feedback is from developers writing comments in Bitbucket :)

While I can't share more specific details about customer feedback or statistics, I do agree that the use case for Bitbucket is indeed a bit different, and we need to make sure it's a great experience for developers (especially being able to create content in the editor efficiently without having to use the mouse).

As I mentioned on the public issue, it seems the common themes are

  • Creating content efficiently without using the mouse - which we've tried to resolve by supporting almost all Markdown + other common keyboard shortcuts
  • Resolving content formatting errors - which we've tried to resolve by making it easier to "break out" of formatting blocks using the arrow keys on your keyboard
  • Bugs - of which we have resolved hundreds in the last year (but keep letting us know if you hit one!)

In your opinion, what problem areas are we missing with the new editor? Can we improve the code blocks? There's also some feedback about pasting Markdown -- is that a key issue for you? Let us know through the Feedback button in the editor itself; we read every comment!



Ah, I see you replied to my comment on the public issue. Let's continue the discussion there, if that's OK!

Individual file comment counts are  missing from the file tree in the side bar. Conflict indicators are working as expected. 

Thanks for the report, Chris. A fix for that issue will be out soon.

I had a really bad surprise today while code reviewing a PR.

With the new interface, a line was (incorrectly) marked as deleted:



When disabling the new UI, the same PR was indicating (correctly) the line as added:


Why? How is that possible?

Deleted user Oct 04, 2018

😲 that it, I'm turning it off for now, the feature needs to go back to the oven, it ain't done!

That is very strange -- we will investigate it immediately! Thanks for reporting.

@Hervé Le Meur, would you mind sending us a link to that PR via a support ticket so we can investigate?

You can open one here:

We'd really appreciate it! Thank you.

Jesse Atlassian Team Mar 26, 2019

I have also seen pull requests where the new view shows a different set of changes from the old view—in one case, wildly different (7 files changed in the new view, vs. 77 files in the old view).

I'm not sure how widespread the problem is, but I have found more than one pull request with this behavior.

I will file a ticket with support for investigation.

Thanks Jesse -- we'll check it out.

Sometimes it is easy to focus on the issues with a new feature/system.  I wanted to be sure to also give my praises for this much needed/appreciated upgrade to pull requests.  Sometimes it feels like I spend half of my day doing pull requests.  Every small improvement you make directly affects my quality of life.  This is such a great update.  Keep up the good work!

Also really appreciate the effort and improvements of the pull requests UI, but disapointed with this half-backed release, between the inline diff not present (which in itself is quite a regression), and the potential bug I've stumble uppon

For a service which main point is development and code management, I find it's odd it has been released in this state.

Like Philip Brown likes this

Dan, thanks for the warm feedback! I've passed it on to the team :)

@Hervé Le Meurthanks for the feedback, we're sorry the initial release has disappointed you.

Obviously critical bugs are not acceptable and must be dealt with immediately.

When it comes to deciding which features to include in a beta release (like the inline diff), it's definitely a tricky balance. For each existing feature, we had to decide whether the upside of that feature was worth the downside of keeping users from trying (and giving feedback on) the new features.

For the initial release, we prioritized features that we were confident were going to be useful all or almost all of the time by most users. Now we can use customer feedback like this to prioritize which additional features we need to bring back first, and users can opt-out if the new experience isn't sufficient for their needs yet.

Such is the benefit of doing a beta! Doing it this way helps us get the general availability release right, so we really appreciate you trying it out and giving feedback. Again, we take critical bugs seriously regardless of whether it's in a beta experience or not.


Deleted user Oct 04, 2018

One other bug I forgot to mention is the link to the JIRA ticket is not rendered in the title like it used to on the previous UI.

Hi Pavel, thanks for the feedback! This feature is noted in the documentation and will be returning soon. We appreciate you letting us know this feature is important to you!

FYI: this feature shipped a while back, but I neglected to update this thread. Thanks!

Not a day too soon. But still, thank you very much for the update it is really appreciated!

Will you include comments in the side-by-side diff also?

Best regards


Yes, we plan to add that in the not-so-distant future. Thanks!

I use the Activity tab every time I do a pull request review. Is this functionality somehow integrated into this new design? I read the article but didn't get this tidbit. :)

Like # people like this

Hi Steve,

It's not there yet - we're working on adding a pared-down activity feed to the sidebar soon.

You can check out all the other existing features we plan to bring back here (under What's missing?):

Thanks for trying the new view!


the activity tab was really important when coming back to a PR we already reviewed and commented on in order to review what had changed since, and it helped identified commit ids to input to branch comparison for that

with the new pull request experience, i would really love for a proper support of the ability to see what changed between two versions of the PR, while staying within the pull request and being able to add comments on the PR. On this part, Azure DevOps does it really nicely, and from memory gitlab does it quite nicely as well.

being able to view the differences between two versions of the PR is particularly important when doing interactive rebases and force pushes during the PR process to take pr comments into account (rather than appending useless commits like “fixed pr comments”)

Agreed.  I would be lost without it.  Glad to see it's at the top of the "coming soon" feature list.

@Alastair Wilkes do you know if it'll land before the new PR experience is rolled out to everyone?  Also, can you elaborate on what you mean by pared-down?  I think all items shown on the current feed are very useful.  I'd be fine if the full text of comments aren't shown, as long as each has a link to jump to the actual comment in the main view (or to expand with a "show more" either inline or in a modal; modal would be best for comments with larger images embedded).

Yes, we will definitely bring back the activity feed before rolling out as the default option! It is a critical feature.

Our current plan is to add a new activity sidebar card. By "pared-down" I meant exactly what you wrote :) We'll ship a basic version and then make it better as time goes on.

Like J likes this

Agreed. I opted out as the new view is basically useless for us without the Activity feed.


Also, having diffs that are not using the `patience` algorithm means PRs are displayed strangely or even wrongly.

I see the Activity card is out now.  :)  Looks great.

@Alastair Wilkes is there any chance it could be updated as events happen on the page?  Right now I have to refresh the page for it to show (for example) comments I've added since the page loaded.

This is probably a nice-to-have and not critical for sitewide rollout, but it would be very handy.

Like Josh Lyon likes this

Hi Jon -- thanks for the feedback. We're continuing to iterate on the activity feed and plan to add that improvement in a future update.

I fail to see syntax-highlightning mentioned anywhere?

Like # people like this

We plan add syntax highlighting to the new view in time, but we need to bring some more existing features over to the new first. Thanks for the interest!

Like Lucas Ribeiro likes this

Glad to hear that! Other then that it looks like a great revamp!

Like Lucas Ribeiro likes this

Hello @Alastair Wilkes .

I am also very interested on this feature. Any news about that?

Just missing that on now to get rid of Google Chrome's Refined Bitbucket extension.

oh.  wow.  How did I not know about that extension?

The tab width customization alone is super nice.  (I know tabs don't have a defined width, but 8 spaces was a bit much, especially where I have it set to 2 in my editor). Highlighting, toggling comments, folding (and auto-folding w/ custom patterns)...

I feel like I've been missing out all this time.  Thanks for the link!

Like Lucas Ribeiro likes this

@Alastair WilkesAny chance syntax highlighting is going to appear anytime soon? GitHub has had it since at least 2011, it's hard to believe this feature isn't supported by a platform primarily used for hosting/reviewing code.

The merge checks are not functional. It is even possible to merge with a conflict. 

Like Matteo Ferrando likes this

Hi David!

The first merge button is still present (we haven't implemented logic to hide/disable it when merging will fail), but if you actually attempt a merge when there are conflicts or failing merge check items, you will get an error and the merge will not succeed.

We are working on bringing this more in line with the old experience soon.


Any plans to offer better support pull requests that are updated via git rebase / force push?

We're not particularly focused on that right now -- but I'd love to hear what you'd like to see!

Having a quick access to the diff between two versions of the pr, whether it is simply new commits pushed or the consequence of a rebase / force push would go a long way (ideally while still being within the pr context and thus being able to add comments to the diff in the context of the pr). 

Like # people like this

Second this. I find versioning of pull requests to be one of the biggest missing pieces in bitbucket. This is available in both gitlab ( and phrabricator.

Like # people like this

Diffs would be nice, but more important to me are that comments stay visible (be it on the commit or the pr level).

I like how github does this:

Note how the comment is still visible on the Conversation tab, but marked as outdated.

Like Sébastien Gautrin likes this

Hey @Alastair Wilkes, I made an app that sends automatic Pull Request reminders to Slack ( and wanted to talk to you about it, however I couldn't find your contact information. Could you please send me a message?

There's cases where changes are no longer visible after merging with the new pull request experience, where the old experience still showed them.

I got a case with a mercurial pull-request where the pull-request originated from before the tip of default (the target of the PR) and contained two commits, the second being a merge of the tip of default in the PR (no reason, just someone who did not follow instructions ;)).

After merging, the new PR experience only lists the two commits but does not show any change, while the old interface properly showed the changes.

I did not see this yet on other mercurial or git pull-requests, but I'd guess it has to do with it being a mercurial pull-request where upstream had been merged in before then pulling the code by merging the PR.

Thanks for the tip Sébastien, we'll investigate this case.

@Alastair Wilkes 

A couple questions:

- what's the best way to stay updated on when features land for the new experience?

- can you tell us which of the planned features will for sure land before general rollout and which will land after that point?

Like Richard Boekweg likes this

Hi there,

Thanks for the questions!

At present, there isn't a great way to stay up to date on improvements. As we ship missing features, we're updating the documentation and replying to comments here where applicable. We will need to revisit this when we prepare to roll out the new experience as the default option in the future -- which gets to your second question.

We plan to ship the new UI as the default experience in a phased manner, aligning customers with the features that are available in the new experience. During this phase, customers will be able to opt out of the new experience (and even with an opt-out, we want to avoid enabling the new experience for a customer if it's missing a feature they use every day). At present, we are focused on improving performance and bringing back important navigation features.

That said, depending on feedback, it's possible that the new UI will be the default experience (with an opt-out) for all customers before a few of the longer-tail features are re-implemented. The "What's missing?" section lists in the lists the major existing features we plan to bring back before making the new UI the only experience (i.e. no opt-out).

Is there a particular feature or set of features that interest your team? Or perhaps any you're using that don't see on that list? Let us know!



Hi Alastair,

I like the new interface, but it lacks most of the original pull request features. Thats why I won't be using the new interface.

I suggest not pushing the new UI as default while lots of features are still missing, like tasks, activity feed, support for renamed files, merge checklists and links to JIRA.

Are you planning on bringing these features back before pushing everyone to the new interface?



Like # people like this

Yep! Definitely. Those features are all the top of the list.

We had a large commit that did not load in the new view.  We had to re-enable the legacy version which give the error message that it cannot load the commit.  Something that would be useful would be to exclude folders from diff view(/Assets/*.png or package-lock.json etc. )

it should still allow you to show them when conflicts exist.

Thanks for the feedback, Dan! We are working on adding the ability to exclude certain files and paths. Stay tuned.

A bit late, but still worth following up: in January, we shipped the ability to exclude paths from the new PR experience.

Learn more here:

Same issue here, excluding files didnt work.


Screen Shot 2019-04-16 at 11.05.41.png

Hi @Tjerk W, if excluded files isn't working for you, give our support team a shout so we can take a look: Thanks!

Like H. Daniel Flores likes this

@Alastair Wilkes  I already did that initially.  This was the response, which i think is not good enough for Bitbucket.

The whole reason we have the exlcuding of files is to make sure it can load big Pull Requests:


We really apologize for the long wait.

Just to give you an update.

As per our developers, the exclude files feature was filtered out after computing the entire diff of your pull requests.
Apparently, the diff is too big to compute in your specific pull request.

Currently, in your pull request, the diff has 12,000 lines of code changes, I'm afraid this is too many for us to handle at the moment.

Our developers are currently looking for ways to work around this issue on our end.


As a workaround on your end, we believe you can do the following:

  1. Review the diff locally then merge the pull request in the UI or over API.
  2. Decline the pull request, chunk it into smaller ones then view the merge.

Thanks, Tjerk.
Apologies for the inconveniences this is causing you and your team.

Hi @Tjerk W,

I see. Thanks for the extra info. We are working on improving that.


be nice if you could hide the diffs for lock files, github does that and PRs are a lot easier to go through since you don't generally care about those files and their like 1000s of lines big.

Like Tyler T likes this
Tyler T Atlassian Team Jun 07, 2019

@Ed Lomonaco , you can! Here is the documentation:

The Excluded files filter is only available in the new pull request experience, and only repository administrators can add files to be excluded from the diff view.

Like Ed Lomonaco likes this

thanks that was helpful :D

Like Tyler T likes this

I want to switch to old view back!

Option in profile settings is not working and I see new ugly and useless UI again and again.

I tired to create bookmarks for each PR at my browser and add manually ?spa=0 to view old-style PR.

Repair it!

Like Alexey Zhurkov likes this

Hi @dost , thanks for your feedback.

You should be able to switch back the old UI by enabling the 'Old pull request experience' feature on the bitbucket labs page. If you've done this and you're still seeing the new UI please raise a ticket with out support team so we can investigate further and try to fix this for you.


Can i set side by side view to default? Ignore white space is also.

Maybe you can remember my last choice?

jarredc Atlassian Team Feb 09, 2020

We're actually planning on launching those improvements in the next 6 weeks!

We'll make it possible for you to select side-by-side as a default, to ignore whitespace for the session, to set your tab width, and to manage your diff add/subtract colors (in case you have red-green colorblindness). 

Like # people like this

This is a much worse user experience! You've hidden button's that were once on the main page behind "...". First I had to find where the hell Edit for PR's went and now I have two clicks when I just had one, you've made MORE work for me.

And in BitBucket fashion you hid more stuff behind abstract icons, like Activity and reformatted it to be useless. Before it used to be it's own button and page, easy to find, easy to review the entire Activity. Now it's hidden behind an icon and all the activities are truncated making it useless.

I wasn't interested in moving to GitHub or GitLab before, but I've now added looking into this option to my Todo list.

Like Robert van der Mast likes this

Hi @jarredc . I can't find the setting for the tab width. Has this feature been released as mentioned on 9 Feb 2020?

Like Jon likes this
jarredc Atlassian Team Sep 14, 2020

Sorry for the lack of reply here! We shipped without that functionality, but someone was working on completing it as their 20% time. I'll find out and get back to you

Like Jon likes this

I am expected batter side by side source code compare for the Pull Request, Why can't we can have a good and easy interface like a Gerrit source code review interface.

@jarredc You mentioned the option to change diff colors:

...and to manage your diff add/subtract colors (in case you have red-green colorblindness

where I can find this option? As of now you prevented attachment preview in old PR view, which basically force user to use new PR view. But then the view that was supposed to be tested by colorblind people ( is a joke. As a colorblind person I spend more time focusing which part was added and which removed than checking the code. 

Can you please revert attachments in old view or at least add the option to change the diff colors in new view to the ones from the old?
Please don't make our live even harder...

Like Jon likes this

@Dawid Majewski  if you find it unworkable and need a solution before Atlassian can roll out the feature, the Stylus chrome plugin is very handy and can be used to override the colors.  You do have to dig around in the DOM to find which classes to target, but it should be doable.  Hopefully they'll roll out the usability feature soon, but that may get you by til then.

(just make sure to grab Stylus, not the once-popular Stylish, as the latter is basically spyware)

Tyler T Atlassian Team Oct 12, 2020

@Dawid Majewski - in the pull request display preferences, you can turn on the Enable color accessibility option. 

Screen Shot 2020-10-01 at 3.10.59 PM.png

Like Dawid Majewski likes this

After the recent update we were unable to find the self approve button in the Pull Requests UI -- is it gone for good?


Log in or Sign up to comment

Atlassian Community Events