Negative language usage (-0.1% C++)

[seanpm2001]

I have noticed some very strange behavior in one of my repositories:

So some background context: this repository contains snippets and template source code for thousands of my repositories, and has source code in over 500 different programming languages (I am a language collector)

Yesterday, I went to look at the Linguist. C++ is one of the top 7 languages in the project, but has been at the very top of the Linguist for a while. It has been rapidly dropping, while the second value has remained a higher percentage the whole time (it has been 0.1% C++, 3.5% HTML, 2.3% C, 2.3% R, 2.1% Python, 1.4% "Forth" (just a mixture of languages that share the *.f file extension, Forth isn't very much of this) and 88.3% Other as of the day before) I noticed that instead of reporting 0.1%, or 0.0% C++ usage, it is reporting negative 0.1% C++ usage. How was this even allowed to happen? You can't have negative percentage language usage. It should have been merged into the 88.4% other at this point, although the numbers would add up to 100% it still isn't correct.

I don't entirely know if this is going to be fixed, but I found it kind of funny.

[lildude]

🤔 this doesn't appear to be coming from Linguist as running on the CLI shows:

➜ github-linguist Git-Templates/
3.60%   3970354    C++
3.60%   3964434    HTML
2.29%   2523197    C
2.27%   2499517    R
2.12%   2339006    Python
1.44%   1585101    Forth
1.34%   1480003    M
1.33%   1467184    JavaScript
[...]

It also took an incredibly long time to run.

I suspect there's an error in the logic used for the percentages in that bar when it comes to calculating the "Other" value and it's having a knock on effect.

The best thing to do is contact GitHub support using the "Contact GitHub" link on the bottom of the repo page and reference this discussion. Support will be able to route the issue to the team responsible for that.

[seanpm2001]

Thank you for your help. I didn't know there were so many layers to the Linguist. I still think that this logic should not have been green-lit for production, negative numbers should never have been supported here. Thank you for taking the real time and CPU time to see what was going on and for giving such a detailed answer. I may contact GitHub about this, but they have a long (~3 year) history of not responding to me, so I am not sure.