Hi all, happy to say we've just released the ability to mark files as viewed on pull requests. Read all about it here!

https://community.atlassian.com/t5/Bitbucket-articles/Keep-track-of-viewed-files-on-Bitbucket-Cloud-pull-requests/ba-p/2497882

Is Atlassian developing features for Bitbucket Cloud AT ALL?

+1

+1

+1

+1

+1

+1

+1

+1

+1

Agreed - this is the only thing preventing us from migrating off of Azure DevOps over to BitBucket.

it has been 10 years sinces it was originallyc reated. I has 122 votes, how many are requiered for it to get developed?

+1

+1

+1

+1

+1

While you gather interest, people are moving in github or azure devops.

Disappointing... 

That's a deal breaker for us.

Go and do it now Atlassian. It is critical for large teams and large pull requests.

How else are we supposed to (thoroughly) review a pull request with 50+ files and 5+ reviewers?

And no, it is not always possible to make smaller pull requests, even if that is desirable.

+1 Please consider this feature. GitHub has it since 2019
https://github.blog/2019-07-01-mark-files-as-viewed/

+ 1

+1

+1

This ability in Azure DevOps is a major part of my workflow and it's hard to recommend to our DevOps team that we migrate to Bitbucket without it.

+1

See github implementation -> https://github.blog/2019-07-01-mark-files-as-viewed/

+1

+1

+1

+1

+1

+1

+++1, 

I figured I would would mention BSERV-4266 is very similar. 

We were using SVN/Crucible (Atlassian product) which had this "marked at viewed" feature.  It was essential for keeping my position on reviews containing +50 file changes.

Its sad that their flagship/supported product is missing the features. 

+++1 Please make it happen

+1

+1

+1

+++1

+1   +1

+1

+1

+1 from me. When there are lots of files in a review, being able to mark individual files as "Done" would be great. I really don't mind how simple it is. Just some way to tick things off as I go.

+1

+1 - doesn't need to be complicated. Just mark file as "ok". if it isn't ok, would have a comment. Would help with large PRs submitted, and frankly even short ones!

As the moment, all I can do is comment on files that are fine putting comments like "Looks good". My developers then have to go through each file, looking for actionable comments. Not a good workflow for them or myself. 

It's good to have a flag indicating per-file approved/not approved.  But I would be best to also have a (full! not just the most recent, in case you accidentally toggle the button) history of past approvals and on which commit the approval was given.  Otherwise, the flag becomes nearly useless if the user has to guess/remember what commit they'd approved up to. 

For similar reasons, it will be critical to easily see which approved files in the PR have had subsequent commits without having to click around to find out.

I really wish PRs themselves had this functionality (separate issue).  On long-running issues with many commits and review cycles it gets to be quite challenging to know where you left off last time.  But as long as each approve/unapprove is just another event recorded per file, that may be the most useful anyway.

We are reopening this issue because this is a feature we plan to add in the near future. Stay tuned for updates and thank you for your patience!

Attachment 2013-08-22 10_54_27-e0ibkf5g.png has been added with description: Originally attached to Bitbucket issue #7968 in site/master

Issue BCLOUD-16222 was marked as a duplicate of this issue.

@acoates - That's definitely true in some cases. That said, commit-by-commit review wouldn't be mandatory; you'd be able to see changes across any range of commits in the PR (including the entire range, like what is shown today). This is especially. useful for "show me what's changed since I last reviewed." Either way, we don't plan to add file-level review states (where some files are approved and some aren't) any time soon.

@awbb - Regarding commit-by-commit reviews - in an ideal world, everyone would craft beautiful commits that were logically isolated. But the reality is that commits in a branch often undo things that happened in earlier commits (ie. where the first implementation of an idea didn't quite work out), so reviewing on a commit basis would waste a lot of time.

Issue BCLOUD-14861 was marked as a duplicate of this issue.

Issue BCLOUD-12523 was marked as a duplicate of this issue.

Hi there,

At this time and for the near future it is more likely that we will solve these use cases by implementing BCLOUD-14889 iterative review (or commit-by-commit review) similar to what's available in Bitbucket Server. This feature would let you review files commit-by-commit so you only have to review new changes.

I think it's unlikely that we'll add file level approval anytime soon - that level of granularity, combined with merge checks, and combined with iterative review, would introduce more UX complexity than we'd like.

This could change as we make more changes to the UI and get more feedback, but for the next 6-12 months I think it's more likely we'll solve this with commit-level review, not individual-file review.

Thanks,
Alastair
Bitbucket PM

Issue BCLOUD-14771 was marked as a duplicate of this issue.

Please also add this functionality to Bitbucket Cloud, not just the self-hosted edition.

This really would be an extremely helpful improvement. We quote frequently have to go through multiple rounds of reviewing large pull request with dozens of files. Being able to mark anything that has been reviewed and approved, and to hide/collapse those files from the view on subsequent reviews, unless there were changes (ideally other than mere whitespace), would save a lot of time and make the process a lot less unpleasant.

I would really love this feature, ↑ up vote ++

Issue BCLOUD-12169 was marked as a duplicate of this issue.

looks promising.

The general idea is to be able to focus the time I have on reviewing to actually reviewing, not just scrolling through aspects that need no review.

Allowing us to configure the acceptance of files modified purely for whitespace - PLEASE!!!!

We have tooling to coerce the formatting as not all developers type the same (Long Live Whitesmith!!! say only me in my office! Sob!). So tooling corrects the styling, static analysis passes sanity, unit tests make sure nothing broke, code coverage does what it does. So, by the time things are in my lap as a reviewer, all the naming conventions, code complexity analysis, namespace usage, etc. have all been covered. I'm not interested in those aspects.

This would be a REALLY useful feature. And will speed up reviewer's work.

Issue BCLOUD-15108 was marked as a duplicate of this issue.

Issue BCLOUD-12984 was marked as a duplicate of this issue.

This is a feature I'd love to see.

Could this be reopened?

This issue has been closed due to inactivity. If you continue to see problems, please reopen or create a new issue.