Total commits shown on the card is way less than actual

[rampatra]

Describe the bug Total commits shown on the card is way less than actual. A single repo of mine https://github.com/rampatra/Algorithms-and-Data-Structures-in-Java has 230+ commits but the card only shows 108 commits in total. The repo is public too.

Expected behavior I was expecting to sum up the commits in all of my public repos. If it can consider private repos then even better.

Screenshots / Live demo link (paste the github-readme-stats link as markdown image)

[anuraghazra]

related to #14 #15

[anuraghazra]

A single repo of mine https://github.com/rampatra/Algorithms-and-Data-Structures-in-Java has 230+ commits but the card only shows 108 commits in total. The repo is public too.

btw @rampatra one thing to note is that the total commit count is not "total commits you made so far since you joined github" its "total commits this year so far"

[rampatra]

@anuraghazra yes, I noticed this in issues you linked to this ticket. But can't we request the GitHub API in a loop asking for 4-5 years of commits (1 year in each iteration) and then sum up all to get the total?

[anuraghazra]

That's what I did in #15

[rampatra]

Ah, I see. So, what's next? Is this going to be merged? Or, would you be just changing the label text to "This year's commits"?

[anuraghazra]

The issue with looping and summing up is the performance, since each graphql request takes time. So I'm finding any other solutions to fetch total commits.

[preyansh98]

@anuraghazra Great work with this!

Is it possible to enable total commits as not the default behavior but maybe as an option in the API?

Maybe another parameter in the request like /?findTotalCommits=true that when passed in will trigger this heavy work? I assume it'll be cached in impl too.

Suggesting this so it doesn't break current API performance, it can just be an additional "experimental" option for those that don't mind the performance delay. What do you think?

[anuraghazra]

@preyansh98 yes that's what is suggested in this comment by @kingthorin https://github.com/anuraghazra/github-readme-stats/pull/15#issuecomment-657535644

Also note that it's not just about the performance delay, since this is running on free vercel serverless function each request would only have 10seconds to get executed before eventually failing, and 10seconds might seem like a lot but actually its surprisingly small, i have tried it with kentcdodds' profile and the request barely misses the 10second mark finishing in 9seconds

[adamyi]

The issue with looping and summing up is the performance, since each graphql request takes time. So I'm finding any other solutions to fetch total commits.

We can use commit search API to get this in single request: https://developer.github.com/v3/search/#search-commits it has a total_count field.

e.g.

curl -H "Accept: application/vnd.github.cloak-preview" https://api.github.com/search/commits\?q\=author:adamyi

but it has a rate limit of 30 queries per minute. It's probably fine for self-hosted instances with cache, but not with the public instance

[anuraghazra]

@adamyi Yeah i think this would actually work! i'm trying to see if i could do it with GraphQL api otherwise i would just do the RESTfull version then

[maddyb99]

What if the label is modified to avoid such confusion? Only until there is a viable fix to the issue.

For eg. "Total commits(2020)" or "Last year commits"

[anuraghazra]

Fixed in #211