Github Stats & Top Langs sudden change / error?

[salesp07]

Did anyone else notice a sudden change in their top langs stats ? Java suddenly became #1 for me, even though I only have 1 repo using it. Javascript and CSS went down 2 positions as well, and it doesn't seem to be related to repos being private.

Edit: I think it is related to repos being private, since my commit count went down too. Even deploying my own instance of this repo, I still can't get the count from my private repos.

[qwerty541]

By default languages stats calculation algorithm uses only bytes count to determine the languages percentages. I guess that you reduced count of CSS and JavaScript code in your reposotories in the last days. Also you are able to change stats calculation algorithm to use repos count instead of bytes count, see details there: https://github.com/anuraghazra/github-readme-stats#language-stats-algorithm

[salesp07]

Actually, I think it might be related to the removal of count_private, as my Github Stats card's number of commits went down a lot (from 500+ to ~100) in the last few days. I even tried running my own instance of the repo and it still didn't count them. Apparently it's a known issue #2793 .

[qwerty541]

Actually, I think it might be related to the removal of count_private, as my Github Stats card's number of commits went down a lot (from 500+ to ~100) in the last few days. I even tried running my own instance of the repo and it still didn't count them. Apparently it's a known issue #2793 .

Recently removed option count_private have no effect on top languages card. It was only stats card option.

[rickstaa]

I agree with @qwerty541. The last changes that could affect the language results were:

• Use compact layout default langs count when hide_progress param was set #2780
• New top language algorithm implementation #1732

I cannot reproduce any problem on my side, but you are welcome to open a bug report if you have a way to reproduce the problems. You can try to deploy the repo after and before these changes and see if the results change. If not, I think @qwerty541's explanation is correct. The code that retrieves the language results is incorrect but cannot be improved due to limitations in the GraphQL API (see #1801 and 7a302f6).