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.

Official response

Comments (51)

  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

    @jgarcia4 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. 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. Jelle van der Ploeg

    We would like this feature as well to exclude the vendor directory in golang projects. @jgarcia4 can you pls consider re-opening this issue since there are a lot of users needing this for different use cases.

  13. 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.

  14. 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.

  15. 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...

  16. 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.

  17. 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".

  18. Christophe Blin

    Ah ok that is what you mean :( Unfortunately, when you have big files (more than 1MB or so I suppose), the content is not display at all so I can not collapse them ... The only workaround we have found is to manually create a tmp branch with the same big files and the PR targets this branch (that way, the diff does not try to show these big files and it works) and then we manually merge the branch to master and delete thetmp branch :(

  19. Dmytro Pylypenko

    Please add this feature with iterated improvement.

    For the first release, just give the ability to collapse / expand files. This is UI Part.

    For the second, it would be great to have the special config file for bitbucket, like .bitbucket_pr. Which can have filenames for not including into review or collapsed by default.

    Like: .bitbucket_pr

    package-lock.json # this will not show the file at all
    # or
    hidden:
      npm-lock.json
      package-lock.json
    
    collapsed:
      *.css
      *.scss
      *.sass
    
  20. Tom Kane staff

    We’ve released a new feature called Excluded files. You can now exclude files in large diffs on pull requests for which you are the admin, so the review process is easier for everyone involved. To enable the new feature, go to the repository containing the pull request and click Settings > Excluded files in the Pull Requests section. Learn more

    The Excluded files filter is only available in the new pull request experience.

  21. Christophe Blin

    Tom,

    First, thanks for hearing the community, bitbucket is becoming more and more powerful everyday !

    I've tried the new feature and it kind of does the job but it is not 100% perfect to me.

    For ex, not diffing the pbxproj file in an ios project is of great value (since the file was at the top of nearly all PRs and is often enormous).

    However, the files are still not really excluded, they are just "not diffed". And so you still hit the problem of the 100th file.

    For ex, if you add a pod in an ios project (they often have 80+ files), you are still unable to process a PR because when you reach the 100th file (which, in my code, is just the 20th file ...), the remaining files are NOT VISIBLE AT ALL (neither in the right panel nor in the main view !).

    So even with the new feature and the "Pods" directory excluded, we are still not able to do a PR when we add a pod :(

    The current workaround we are doing is 1. create a branch with the pod and push it 2. create a branch from this branch and do the work 3. PR the second branch into the first one instead of into the master (so that the diffs are visible) 4. manually merge the result branch in master (without a PR)

    This has a lot of drawbacks : - you have to remember to do it that way (if you commit the pod without pushing a separate branch, you're good for a lot of git wizardry to create the branch afterward) - if you have not done a separate commit for the pod, you're screwed - the resulting history in master is not as clean as a PR - the manual merge has to be carefully done (for ex, dont forget to pull master before doing it...)

    What I suggest to solve that 100th file problem is to really exclude the excluded files (i.e showing them in a separate panel on the right after the regular files and displaying their "empty" diffs at the end of the regular files instead of in the middle). I think it will be useful everytime a directory is excluded (for ex, generated code outside of the build, external sources included in the project for any reason, etc...)

    Do not hesitate to contact me if you need any more details or testing.

    As a side note, we have no return when we use the "give feedback" button in the new PR experience (for ex, what about enlarging the right panel so that we can read the filenames and to keep the comment section of the top always visible).

  22. Alastair Wilkes staff

    Hi @Christophe Blin,

    Thanks for using the new experience and providing such detailed feedback.

    What I suggest to solve that 100th file problem is to really exclude the excluded files (i.e showing them in a separate panel on the right after the regular files and displaying their "empty" diffs at the end of the regular files instead of in the middle). I think it will be useful everytime a directory is excluded (for ex, generated code outside of the build, external sources included in the project for any reason, etc...)

    This is a great idea!

    One thing to mention: it's not obvious, but the 100 file limit is actually temporary. We are working on supporting more than 100 files in the file tree right now. But I totally get that this feature's utility is limited until we fix that.

    However, even after we ship that, I agree that excluded files/directories may clutter the tree. We're about to ship a change to automatically collapse excluded files in the diff section; we could add that to the file tree, too. But I like the idea of moving them to a separate section. As with the rest of the UI, we'll continue iterating to improve the experience.

    As a side note, we have no return when we use the "give feedback" button in the new PR experience (for ex, what about enlarging the right panel so that we can read the filenames and to keep the comment section of the top always visible).

    Because we get a lot of feedback, we usually only contact users when we have questions about their submission. Sorry if it feels like a "black box" -- feedback is very influential in shaping what we work on, and we've incorporated lots of feedback already.

    With regard to those specific concerns:

    • You can adjust the sidebar's width now, but the width is not preserved. We may add this in a future update, as we've received a lot of feedback about it
    • We haven't heard much feedback about keeping the comment section always visible, but we'll take action if that becomes a recurring theme

    Thanks again,
    Alastair
    Bitbucket PM

  23. Log in to comment