Optionally disable diff on specific files in a pull request (BB-11005)

Issue #10032 open
Anonymous created an issue

We've got a few repositories which keep "built" css and javascript files checked in. We need to check these files in so our package manager (component) is able to access them at install-time, rather than forcing it to pre-process our stylesheets/templates (stylus, less, jade, whatever).

My request is that we can somehow tell the pull request view (https://bitbucket.org/user/repo/pull-request/XYZ/) to not display a diff on a few specific files. This could be a setting at the "Create pull request" step, the repository settings panel.. anywhere, really. This would make code reviews significantly easier and much faster.

An example repo structure would look like this:

$ tree
.
├── Makefile
├── Readme.md
├── cache.js
├── component.json
├── example.html
├── index.js
├── package.json
├── style.css # ignore diff
├── style.styl # show diff
├── template.jade # show diff
├── template.js # ignore diff
├── test
│   ├── cache.js
│   ├── generator.js
│   └── index.html
└── test-server.pid

Comments (60)

  1. Jeff Clark

    Some files updated by development tools are re-generated or re-scaffolded but are not of value to a code review / pull request. This would be a great feature; please tell your friends to vote for it.

  2. Tom Worster

    composer.lock, js and css files generated by build script, combined, and combined+minified, plus their source maps, they all need to be in the repo but it makes no sense to display them in a commit or PR diff. indeed, Bitbucket's client script for displaying the diffs typically gives up because of these "object" files that ire irrelevant to code review

  3. Jeffrey Labonski

    +1

    npm's package-lock.json is a utter mess of noise in a PR. Must be checked in, can't be meaningfully reviewed. Man, it'd be great to have some clickable HIDDEN icons next to the file list and hide the diff's div by default.

  4. Daniel Walz

    +1 Using C++/JUCE where many files are autogenerated. We don't want the project generator to be installed on every developers machines, hence we put the generated code in source control. Hiding certain files or folder would be really helpful (maybe not necessarily hiding it, but having them collapsed, so the meaningful diffs could be easier spotted.)

  5. Ronald Rey

    Hello guys,

    I am the current maintainer of the Chrome extension refined-bitbucket and I've just released version 3.0.0 a few minutes ago. That version has two new features which I developed specifically to tackle this issue, "autocollapse" and "pullrequest-ignore", among others.

    Check out the README on Github to see some screenshots and gifs and a description of other features available on it. If you find any weird behavior or have any ideas for possible improvements let me know through an issue or hit me up on twitter @reyronald.

    Hope you can find it useful since apparently there's no intention for this to be solved natively by Atlassian.

  6. John Aitchison

    Pageload performance differences on a pretty small PR but which includes a handful of built files:

    Github: 5.2 seconds

    Bitbucket: 70.1 seconds

    We chose Bitbucket initially because of the "enterprise" features e.g. branch permissions, but this sole issue has forced us to switch to Github (which now has more enterprise features like branch permissions).

  7. Claire Bianchi staff

    We are actively working on improving the performance of large pull requests but it requires substantial amounts of work. This work has started and we are targeting the beginning of summer.

  8. Pierre-Henri Trivier

    @Claire Bianchi I'm not sure what you mean by "improving the performance of large pull requests ", but it seems like your customers are not asking to "improve the performance of displaying big useless files in PRs", they're asking for "being able to HIDE big useless files in PRS". (As, not only are they big, they're also, you know, useless and all.) Will your improvements cover that ? In which case, good luck with the implementation, and thanks for the reply !

  9. Peter Klooster

    I wanted to chip in and confirm what @Pierre-Henri Trivier said; This issue isn't about performance, it's about auto generated files cluttering up our pull requests, so we want to hide them. "Improving the performance" doesn't fix this issue at all. (Also do note that hiding files from the diff does improve performance though)

  10. Sam Megidov

    Came here to repeat what was said by the last two gents above me.

    @Claire Bianchi It's not about performance, but rather about hiding files that we do not care about when doing a diff. An example of this would be the .meta files that come with EACH file inside Unity projects. Changes in those files aren't important for us, but it does matter for the project itself ( so .gitignore is not a solution ).

    For instance, a change of 10 files in Unity ends up with 10 additional .meta file changes, I always ignore those meta files.

    We simply want to the ability to not include diffs of certain files, so that when I review code I don't have to hurt my finger scrolling past all those irrelevant meta files

  11. Ronald Rey

    @Pierre-Henri Trivier, @Peter Klooster @Sam Megidov, @Marcos Silva, @Greg Zapp

    My team and myself were having this issue ever since we've been using Bitbucket, and it was making the code review experience so unbearable to me that I decided to solve it myself. I already mentioned it above in a previous comment but going to do it again just in case some recent participants haven't seen it and would be interested in using my solution.

    I implemented three features in a Chrome / Firefox extension that I maintain called Refined Bitbucket. With it, it's not only possible to manually collapse certain diffs, but it's also possible to specify which diffs you would like to automatically be collapsed or completed ignored (diff removed from the page entirely) through the Options page, in a very similar fashion to .gitignore files.

    Details of all other features and how they work are documented in the official repository here https://github.com/refined-bitbucket/refined-bitbucket, and they are all optional, meaning that you can disable any that you don't particularly want.

    Here's a GIF of the manual collapse in action, just to grab people's attention that might be skimming through the thread. Oh, and yeah, the extension enables syntax highlighting as well.

    I31857910-3938deb6-b6b8-11e7-8bac-f55242010a62.gif

    I apologize if anyone considers this spam.

  12. Alastair Wilkes staff

    As Claire mentioned, we are working on improvements to the pull request UI, and as of right now we expect the ability to optionally disable the diff for specific paths to be in scope. We'll update this issue when we have more info.

    Cheers,
    Alastair

  13. Patrick Nelson

    Unfortunately the Refined Bitbucket plugin doesn't help in my situation. While it'll make a PR/Diff more readable by allowing you to collapse specific files, if you still have a large number of files or it just takes BB a very long time to render the diff, you're still out of luck. In fact, the extension adds more overhead to the initial page load, freezing it and making it even more difficult to use (so I had to disable it).

    Ultimately this request has sat since 2014 and the "duplicate" (#3564) has languished since 2012, so it'd be nice to see some progress on this server-side (i.e. on Bitbucket) since client-side in-browser solutions can only do so much.

  14. Jeff McBride

    +1 We sometimes commit intel hex files containing essentially binary data encoded in an ASCII format, and these walls of uninteresting text very much get in the way on the pull request view.

  15. Ken Dellinger

    +1 for noise files like package-lock.json.

    +∞ for Ronald Ray and his Refined BitBucket plugin.

    I'm still getting the "Oops! You've got a lot of code in this diff and it couldn't load with the page. Click here to give it another chance." messages for EVERY file that is in the same commit as package-lock.json, so a real fix from Atlassian would be a ... Herculean improvement. :D

  16. Log in to comment