Issue #10463 wontfix

Allow hiding irrelevant files from pull requests

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 (15)

  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:

    http://blogs.msdn.com/b/lifenglu/archive/2007/05/08/files-in-a-service-wcf-references.aspx

    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. Andrzej Pisarek

    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. Log in to comment