Issue #7882 resolved

Unable to see diff for some files (BB-9125)

Paolo Inaudi
created an issue

In a pull request I have a file I cannot review. Opening the pull request I see my 20 files modified and all of them are hidden with "This diff was too big for us to render on page load. Click here to try to load it". If I click, every file loads except of one, that says: "While impressive, your diff is just too big!". I have no way to see the diff on bitbucket. When I've seen it via command line, however, it turned out the diff was something like 10-lines long, and the affected file was 118 lines. Nothing big at all. Seems that you are addressing https://bitbucket.org/site/master/issue/7723/improve-performance-of-large-code-reviews, but the fix causes troubles with smaller code reviews. Also the whole pull request is not really big, and I don't see the point in having me to request the opening of each single file. Maybe when there are thousand lines I can understand, but with 1 or 2 hundreds this is too aggressive. More, randomly happens that when I load the page, instead of viewing the list of changed files, I only see a line: your diff data was too big, and I cannot see nothing but the pull request description, which is not really useful!

Official response

  • Jonathan Robson staff

    It seems there are multiple problems being reported in this issue. Also, the underlying code that generates most of the diffs on Bitbucket was almost entirely rewritten during 2015, with the new version being much more performant and less buggy. Because a lot of the comments on this issue were from before that rewrite, and because it seems like there might be a few different issues being reported, I'm going to close this. If you're still having a problem, feel free to create a new bug report about your specific problem, we'll focus on it separately from this issue.

Comments (49)

  1. Samuel Haddad

    I am also seeing this issue. IT also happens when you do a compare of new branches, not just a pull request.

    I will see the message "This merge is too large to display" again this diff is relatively small. only around 100 or so line.

    If I go to the individual commits the issue happens on a per file basis, some of these files only have 10 or so lines changed.

  2. Paolo Inaudi reporter

    While I haven't seen this for some days, today it comed back. But it continues to be a non-deterministic thing, sometimes you only need to refresh the page, sometimes it keeps saying "This merge is too big to display".

  3. Paolo Inaudi reporter

    I've opened diffs for all our branches, and no, I can't see this message. I will let you know if it appears again. A little thing: one of the branch diff was quite huge, and has been preloaded only for an half; for the other half, I had to click on each file to load its diff. This worked, all files were loaded, but while is quite a good thing that the system is not forced to load the whole diff on very large comparisons, I would appreciate better a system to load more than a file at once. Something like: page is filled only with, say, 100 files. When I reach the bottom (or better, while I'm near the bottom) a script starts to automatically load next 100 files. Or I can also live with a button to click, "Load more files" instead of being automatic, but I don't think there would be a huge difference in needed effort... But maybe you want this to be reported in a new bug?

  4. Timothy Hruska

    I haven't seen the "While impressive" message in the last few days. I am still seeing a page with 11 files changed where only the first four files loaded the diffs, and the rest had the "This diff was too big for us to render on page load." message.

  5. Jon

    I'm occasionally seeing instances where a file where only a line or two were changed in the commit, but the pull request is showing the whole file as it was previous to the commit as deleted, immediately followed by the whole file as it was after the commit as additions.

    It may be that this is similar to what's happening to other users but that once the file contains enough lines the original-plus-doppleganger is just too much for the browser and triggers whatever logic decides that the 'while impressive' message should be displayed instead.

    I'm not sure if this is related to the issue I'm seeing almost all of the time where the changed lines are light red/light green, but the specific intra-line changes themselves aren't highlighted in the darker red/green colors.

  6. Zachary Davis

    Hi Tracy,

    We've recently increased the timeout that triggers the "diff too big" message so those messages should be less frequent, but the actual underlying issue requires some non-trivial changes to some of our servers. Those changes are scheduled for later this week.

    Cheers, Zach

  7. Brent Dearth

    for git renames, it would be nice to just see something as simple as:

    '/path/to/orig_file => /path/to/new_file'

    ... rather than en entire diff. Similar strategy for deletes. I imagine that would help to ease the rendering pipeline a bit.

  8. alex jacobs

    I have recently run into the same problems Jon Anderson mentioned in that my commits are showing the full previous version of a file in red followed by the new version in green. This hasn't caused a 'diff too big' yet as I am only dealing with a few files at a time.

    It may also be worth noting that so far these have displayed fine in the 'side-by-side' view for individual files.

  9. 俊介 三原

    Same here! This issue is critical. Teem policy doesn't allow code reviewer to clone code developer's repository. Code reviewer show only master repository pull request.

  10. Yang Zheng

    This is driving me crazy, it made the code review impossible as it didn't show the actual changes, esp when the file is large. I changed the line ending but it didn't help.

  11. Abhin Chhabra staff

    Hi everybody,

    I'll be working on this issue and will try to get to the bottom of what's going on. The timeout we use is large enough that you shouldn't see its effects for small diffs. But since you are, there could be something else going on here.

    Here's my ask: when you find that this happens again, could you please also include a link to the specific pull request where this is happening? It'll help me understand if this is strictly a timeout or a bug.

    Thanks you and sorry for the inconvenience.

  12. Jonathan Robson staff

    Nicolas Leblanc: That's a separate problem than the one originally reported in this issue. The screen that you see in your second screenshot is because we didn't detect any changes between those branches. The original problem reported in this issue was the diff not loading because of timeouts and truncation where people were getting specific error messages about the diff being too big. I would first double-check that you're diffing the same branches in the command line that you're diffing on Bitbucket and that your local copy is up-to-date with the repo on Bitbucket. If you still see the problem after that, can you create a separate issue for it?

  13. Nicolas Leblanc

    Jonathan Robson, thanks for the follow-up. As you stated, it is not guaranteed that my command line diff is comparing the same dev branch: I might've messed up.

    However, as the 1st 2 screenshots demonstrates, the features branch is ahead of dev by 2 commits. However, the branches comparission pages states that the branch contains no changes.

    Once again, this could be due to some mistakes on my sides, so I understand your point. I just want to point out that I am pretty confident the 2 commits are "not cancelling each-other" as they included features that actually/successfully ended-up in my product release.

    At this point I have not encountered this issues again, moreover, the branch diff's page issue resolved itself after I push a 3rd commit to the branch. I'll open an issue if the issue occurs again.

  14. Jonathan Robson staff

    It seems there are multiple problems being reported in this issue. Also, the underlying code that generates most of the diffs on Bitbucket was almost entirely rewritten during 2015, with the new version being much more performant and less buggy. Because a lot of the comments on this issue were from before that rewrite, and because it seems like there might be a few different issues being reported, I'm going to close this. If you're still having a problem, feel free to create a new bug report about your specific problem, we'll focus on it separately from this issue.

  15. Jonathan Robson staff

    Nicolas Leblanc: It's possible that there were merge commits or cherry-picked commits that indeed made one branch "ahead" of the other, even if there were no actual changes. For example, if someone merged the dev branch into the features branch using a non-fast-forward merge when it could have been a fast-forward merge, then the two branches would mostly have all the same commits except features would have an extra merge commit that's not on dev, even though there are no actual changes if you diff the two branches.

  16. Log in to comment