Issues

Issue #7882 open

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!

Comments (33)

  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 Anderson

    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. Zach Davis staff

    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. Curtis Nolan

    Same issue here. I certainly understand the logic of having a timeout, but can this be increased? It's making bitbucket unusable for some large repositories.

  10. 俊介 三原

    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.

  11. Log in to comment