Try out the new Bitbucket Cloud pull request experience today!

[Alastair Wilkes]

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

[Alastair Wilkes]

Hi Tim,

Thanks for the feedback! While it is possible to view and comment on every line (including context lines) in Bitbucket Cloud, you can't easily expand the whole file for viewing and commenting -- you have to manually expand context between diff hunks. We're looking at improving that in the future.

On the Bitbucket Server side, there is an open feature request to support comments on context lines here: https://jira.atlassian.com/browse/BSERV-3749

Thanks!

Alastair

[Alastair Wilkes]

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

[Alastair Wilkes]

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

[Dan Cumings]

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

[Dan Cumings]

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. )

[Alastair Wilkes]

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!

Thanks,

Alastair

[Alastair Wilkes]

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

[Alastair Wilkes]

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!

[Alastair Wilkes]

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

[sgautrin]

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.

[Alon Diamant]

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.

[Jonathan Piche]

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.

[Michal Mazurek]

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

[Alastair Wilkes]

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

[Alastair Wilkes]

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.

Thanks,
Alastair

[J]

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).

[Sébastien Gautrin]

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”)

[Martin Ulmschneider]

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

[Alastair Wilkes]

Glad you like it!

[Alastair Wilkes]

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?): https://confluence.atlassian.com/bitbucket/try-the-new-pull-request-experience-in-bitbucket-958455255.html

Thanks for trying the new view!

Alastair

[Dan Cumings]

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

[Alastair Wilkes]

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

[Alastair Wilkes]

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.

[Pierre_Fransson]

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

Pierre