Allow hiding irrelevant files from pull requests

Issue #10463 wontfix
Stephen Jennings
created an issue

In .NET, updating a WCF service reference can generate huge changes in a dozen generated files, none of which are relevant to understanding what a pull request is really changing.

When creating a pull request, It would be nice to mark files in the pull request as "irrelevant" so they are hidden from reviewers by default.

The reviewer could unhide the changes, but usually seeing several KB of svcinfo and xsd files changing is unhelpful.

With this feature, reviewers would be directed at the important files in the pull request and the boilerplate changes would be hidden.

Comments (43)

  1. John Garcia

    The best way to avoid including files in commits or their generated objects (such as pull requests) is to use the .gitignore file to specify which files should not be version controlled.

    We're no .net experts, but based on this conversation on Stack Overflow, those files should not be version-controlled.

  2. Stephen Jennings reporter
    • changed status to open

    @John Garcia Ignoring those files may cause more problems than it solves. The svcinfo and svcmap files aren't part of assembly compilation, but they are used by Visual Studio to keep track of the options you used when creating the service reference (so it can use them again when you update) and to keep track of changes it's made to the web.config (so it can edit them when you update). See this blog post:

    In addition, Visual Studio puts references in the csproj file to the wsdl and xsd files. These files missing doesn't break assembly compilation, but it does break the "package" MSBuild target because it's expecting to find those wsdl and xsd files. To get around this, every time you update the service reference, you'll have to edit the csproj file and remove references to those xsd and wsdl files.

    This is way harder than just using the product as it's designed by including these files in the repository.

  3. Jon Rasmussen

    I don't know if it is proper to put comments in an old Won't Fix work item, but this feature would be useful for game development in Unity3D, as well. When you submit a pull request with meta files, these can clutter up the pull request terribly during code reviews. Having the option of collapsing certain file extensions on a team/ project basis would be helpful (not completely hiding them, but putting them under a Low Priority heading at the end of the pull request or something similar). Meta files for Unity3D are definitely required for collaboration, so it is not a problem easily solved by .gitignore changes.

    This is something that has made code reviews more difficult on Unity projects, at least.

  4. Jørn Lomax

    I don't like just adding +1, but exactly what Jon said. We are using bitbucket with unity3D and it becomes very difficult to find the one change that needs reviewing amongst the 20 or so meta files

  5. Sage Gerard

    @ John Garcia, are you saying that an answer to one case on Stack Overflow with 11 votes holds more weight than customers telling you what they want?

    At my shop we have autogenerated files that, even if they weren't supposed to be under version control, are mandated to remain by management. What people say should happen doesn't help us.

  6. Adrien Carré

    Just to add my weight to it : with webpack/gulp or any javascript compactor/translater, both the source and the generated files needs to be in version control because : 1- Some dev won't work on it so won't create them 2- They shouldn't be created on the production server as it requires several un-necessary javascript library

    But those file are completly irrelevant to PR because it's the source that is reviewed.

    So, please, add a .pr-ignore-file or something.

  7. Dustin Nielsen

    I heavily agree with needing this feature. In my project, we use a framework that is compiled with many different vendor plugins. Whenever we update those plugins, we absolutely have to commit those changes as the application won't work without them, but there's never a need to code review any of those files as they aren't created or edited by the team. We're talking hundreds of files that destroy any sensible way to do a decent code review.

  8. Anonymous

    I think that a simple option to hide diff for specific file or specific file format would be great. I'm using Jupyter Notebooks which are stored in JSON format and there is a lot of metadata changed between running them. It is cluttering the code review.

  9. Sage Gerard

    I'm unwatching this thread because I'm tired of the notifications, but some parting thoughts:

    To the people who continue to reply, it doesn't matter what your proposed solution is for BitBucket so long as there is a big, red "WONTFIX" at the top of the page. Even if the wontfix status was ill-informed, all it takes is a cursory glance through this thread to see how low this is on Atlassian's priorities.

    But if you want an ignore-like feature for checked-in files, use this until the feature becomes available.

  10. Xavier Arias

    We need this feature on Unity game engine because of meta files. Is bitbucket going to ignore us and that's it?

    Is there any procedure to see if a feature has enough user demand?

  11. Michael Ernst

    This feature would be good for golang vendoring as well. Basically you want to store a local copy of your dependencies due to how vendoring works but you do not want to see each file in the PR because it makes PRs unreadable.

  12. Trevor Jex

    +1 for hiding package-lock.json files. Especially when they're at the very top of the pull request. Makes reading through everything else super annoying.

  13. Lars-Kristian Svenoey

    +1 From me as well, this would be a tremendously useful feature for us as well! We use Unity3D which produces a lot of .meta files that are not interesting to review, which will ocassionally break PRs due to size. Also, what about generated code? I can see plenty use-cases for this.

  14. Alex Rosenthal

    +1 for hiding yarn.lock and similar. it's kind of ridiculous that BitBucket ignores their users for YEARS... you know what happened to Stride and HipChat? same thing will happen to BitBucket if you don't listen to your users...

  15. Mustafa Mansour

    We use Sass which is compiled down to CSS. We don't care about seeing the .css files in PRs because they're a result of the SCSS. If we add them to .gitignore then they won't get committed and the page will look broken. I think this is a valid feature request.

  16. Trevor Jex

    There's a new pull request view available in Bitbucket that solves a lot of problems including this one. You can enable it by clicking on your profile picture > Bitbucket Labs and then toggling "New pull request experience".

  17. Log in to comment