You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I am currently working with a PR that has 309 changed files, 247 of which are tracking metadata in an ignored directory (specifically, it is the `.todo-lint` directory for `ember-template-lint`).
This, of course, flips it into a "large pull request", even though 80% of the file diffs are totally useless to a human reviewer. I was excited to find out about the Exclude Files functionality, and excluded that directory.
Unfortunately, the implementation of the Exclude Files functionality makes it totally useless for my use case. It simply hides the diff, as if it were a too-large diff, and the "excluded" files still show up in the list of diffs and result in the PR being "too large"
Without the excluded files, it would be a reasonably-sized diff that would be perfectly suitable for the normal pull request view.
I think the Exclude Files is a great feature, but I think its implementation hampers its usefulness. It would be much more useful if I was given the usual (non-large) pull request experience with a note that said "247 files have been excluded, click here to see them" or something, instead of being forced to review the 247 ignored files one by one, in addition to the rest of the diffs that I actually care about.
I can see how this features is useful for certain cases (concatenation/minification?) where the number of ignored files is small, but I imagine there are plenty of use cases where that is not the case. If excluded files were excluded from the pull request size for the purposes of determining if it is a "large" pull request or not, I think it would be a great improvement, and certainly would be for my use case.