Our problem

We have a lot of generated files in our code, that are human-readable in theory, but completely useless in a pull request.

We would like those files to either:

• not appear in the pull request at all,
• or be automatically collapsed in the pull request view
• or at least be sent to the bottom

Also, we understand that bitbucket can not "guess" which files are generated, so we want to be able to specify it, by project, with a simple text file.

Related issues

There are a couple issues "related" to our problem, but they have been long running, and the noise is now bigger than the signal.

7086 ("Ability to collapse or minimize diffs in pull requests")

This issue was opened a while ago, and marked as "resolved" after the release of the "New pull request experience":

BCLOUD-7086

In the "New pull request experience", given a pull request with many generated files, you can now:

• open the PR
• seen hundreds of generated file
• click on each file to collapse them

I understand why this resolves the specific issue, strictly speaking; unfortunately, it does not help much in the case of many generated files.

7723 ("improve performance of large code reviews")

This issue is also long standing too :

BCLOUD-7723

I don't know what resolution the Bitbucket team has in mind for this.

However, the problem of "big" PRs exist regardless of generated files, so it's a different issue.

What I suspect people want

As it's been pointed out elsewhere, a solution exists in other products:

https://robots.thoughtbot.com/github-diff-supression

• let the developers speficy, per project, a list of file extension of generated files

# In a `.gitattributes` file
*.asset linguist-generated
*.mat linguist-generated
*.meta linguist-generated
*.prefab linguist-generated
*.unity linguist-generated

• treat "generated" files specifically

_(You probably know this already, and I'm sorry for pointing out competition - I know how frustrating it can feel to be compared...
Also, it's obviously linked to linguist, but a similar solution could be implemented.)_

@awbb : seems like you've been looking at those issues, could you clarify if there is an intent to implement this solution in the future ?

@all : I suspect "+1" and "mee too" comment would not be necessary