Why I'm getting below information while reviewing the code, since I'm having only few changes in the code
"Now that is a lot of code! There's simply too much in this diff for us to render it all."
While investigating this further I came across two improvement requests that relate to this message you're seeing:
Feel free to vote on these improvements and watch them.
While they are not available, as a workaround you can split the number of changes into smaller chunks so that others can view the PR in the UI before merging or review the changes locally, merge the PR and then push to Bitbucket.
The official response from Bitbucket staff on the feature BB-7555, in 2018-03-07, was:
Howdy! thanks for your continued interest in this ticket. We are currently working on an improved Pull Request experience; the project is in progress and should be available as a labs feature in the coming months. While the initial labs feature may not address all performance issues regarding large commits, it will continue to be improved upon over the course of the year. I will update this ticket with directions on how to turn it on once ready.
As can be seen, that feature is still being worked on, but there is no planned release date yet.
Please have a look at the Implementation of New Features Policy for further information on how new features and improvements are prioritized.
We appreciate your understanding.
No disrespect here @Felipe Kraemer but they are not working on it they have had 8 years since the first issue reported, and 2 years on the other. If they wanted to take this serious blocking issue seriously they would have by now. No other online GIT source control provider I have ever used has this issue only Bitbucket. PR's are the best way to have a code review and conversation about changes on their way to another branch. The FACT that Bitbucket has this "Oops" message is a joke, that this is not a serious source control service. This should never happen as when it has the first "oops" it just oops all the way down for the rest of the files.
This is a horrible experience. Because the one that it first failed on when retried seems to always fail again and then you only get that on retry and you are screwed. You cannot provide any direct line by line comments for the PR on that file.
Then we have to retry each any every file after that one and usually, they all work just fine on the retry. SO first Atlassian sucks at source control, second, they get one issue on one file and then just give up on the remaining files. They provide only one retry. They then require the user to manually retry all the rest of the files on my one which takes a while depending on the number of files.
If you cannot handle refactors then get out of the source control business, please. If you have 400 files that changes because you renamed a couple of methods and you fail and give up and then have 300 files with Oops" message you suck at your job of providing git source control.
If you cannot handle a huge refactor on a single file then you suck at your job of providing git source control.
Please stop trying to compete with the real providers of source control and git out of the business. As you clearly after 8 years on this "Oops" issue do not care about your users and do not take PR's seriously.
This continues to be an annoyance with the Bitbucket pull request UI. Many times, the actual file diff is small, so clearly there is a problem with the Bitbucket implementation. Furthermore, when the diff is not displayed, it obfuscates any comments that other developers added during the pull request code review process; which then requires that every (minimized) diff must be manually opened, to check for comments. Not good.
Not sure how the accepted answer is to point the user to two ignored feature requests one that is over 8 years old and the other that is over 2 years old.
The solution is for this to be considered a BUG and for Atlassian to get off their A$$'s and fix this crap. How can they have a source control solution that supports GIT and PR's and it cannot show you a diff that is required for a code review to occur which is one of the many great things about GIT and PR's.
This is a blocking issue that prevents code reviews from occurring within the PR itself where they belong.
Atlassian time and time again ignores real bugs, treats them as "Suggestions" and then ignores them for years and years. Even bugs they agree to accept as bugs typically get the same treatment.
We as the users need to talk to the person in the company who controls the decision of what source control vendor we use, especially for cloud-based ones. Then we need to get them to switch to GitHub or Azure DevOps both of which do not have this issue and have always worked flawlessly for me at other companies that used them.
We as real users are typically not in control of the decisions like this and are forced to use the tools provided. This is sad but a reality at many companies. It is easier than ever to migrate from one GIT based cloud provider to another and not lose any history.
We should find ways to show that Atlassian products are a bad value and they cost the company more money than they are aware of based on lost productivity they cause on a daily bases from Bitbucket and Jira being the worst offenders but Confluence isn't far behind.
Hi everyone, The Cloud team recently announced 12 new DevOps features that help developers ship better code, faster ! While we’re all excited about the new improvements to Bitbucket ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events