Add options/settings to ignore specific files (using pattern if possible) in the lines count in PRs.
Changes in yarn.lock files, for example, can include thousands of lines, while actual code changes in the PR can be minimal.

It would be very useful to be able to remove that count from the PR summary, while still showing it somehow (maybe through a tooltip?).
We can remove line count for files with collapsed diff. But I think the default should stay and we can the reduced shortstat on hover or next to the original.
Basing this on collapsed diffs might not be ideal as collapsed diffs may actually be real code changes in a PR, in which case stats must be counted.
This feature would be to ignore count for specifically chosen files where changes don't need to be reviewed, and could be used as an explicit opt-in setting to make sure useful stats are not missed out.
This essentially requires the same UI as #1085, which was rejected.
Refer to https://github.com/sindresorhus/refined-github/pull/1085#issuecomment-368478152
Not to say that it鈥檚 not useful. It鈥檚 welcome as a separate extension.
Sorry for necropost but this one sounds good actually. I randomly got here from google trying to find out if it's possible. Though, I don't see how is that possible with a browser extension. I think maybe it shouldn't be even Github responsibility, maybe some git extension like git-lfs or just newer version of git.
I would even say it's having this in .gitignore:
yarn.lock
And having this in something like .repositoryignore:
!yarn.lock
So it won't be treated as code, but still will be pushed into repository... Well, wait! Just ended up with that git-lfs is actually enough for this purpose lol. So the change will be not the whole file of hundreds or even a thousands of rows, but will be just a single row, - a different hash of whole yarn.lock file. However, it may turn out to break things, because the files are formally not in the repository but inside an external storage.
Sorry for necropost but this one sounds good actually. I randomly got here from google trying to find out if it's possible. Though, I don't see how is that possible with a browser extension. I think maybe it shouldn't be even Github responsibility, maybe some git extension like git-lfs or just newer version of git.
I disagree of it being responsibility of git itself, this should be part of the service. In bitbucket the API provides all sorts of data, so someone in my organization developed a chrome extension that counts the diffs manually (since it's a missing feature from bitbucket) but disregards a few patterns like test files, svgs, and package-lock.json. The diff for package-lock json is still there, which is a desired behavior, just does not count in the lines changed.
The same extension can possibly be done for chrome for github, but it'd be preferrable if the portal provided that feature instead. It helps us track how big a PR is and impose limits on how big it can be before it should be broken into smaller PRs
This seems to be possible since the file filter does have this information per-file:

But it still doesn't belong to Refined GitHub. If anyone is interested, please suggest it on https://github.com/sindresorhus/module-requests and mention it in:
https://github.com/sindresorhus/refined-github/pull/1085 (has the starting code)
https://github.com/sindresorhus/refined-github/issues/1316
https://github.com/sindresorhus/refined-github/issues/1395 (current issue)
Most helpful comment
Sorry for necropost but this one sounds good actually. I randomly got here from google trying to find out if it's possible. Though, I don't see how is that possible with a browser extension. I think maybe it shouldn't be even Github responsibility, maybe some git extension like git-lfs or just newer version of git.
I would even say it's having this in
.gitignore:And having this in something like
.repositoryignore:So it won't be treated as code, but still will be pushed into repository... Well, wait! Just ended up with that
git-lfsis actually enough for this purpose lol. So the change will be not the whole file of hundreds or even a thousands of rows, but will be just a single row, - a different hash of whole yarn.lock file. However, it may turn out to break things, because the files are formally not in the repository but inside an external storage.