shields
shields copied to clipboard
badges
Badge Request: GitHub Total Commits Badge
:clipboard: Description
The badge is for displaying the total amount of commits to a GitHub repository.
Example:
:link: Data
There is no clear way to get the total number of commits to a repository.
One way is to get all the contributors to a repository using the GitHub API and add the contributions attribute of each to get the total number of commits. Here is an example. This is not a robust solution, however.
This article details a more robust solution, however, it is a "hackish" solution.
:microphone: Motivation
There are badges for weekly, monthly, and yearly commits, however, there is none for total commits. This badge would be useful in helping users get a better idea of the project's dependability.
A large number of commits generally correlates with a more robust and maintained project, improving its credibility. Conversely, newer projects that are more likely to undergo breaking changes will have a small number of commits (even if they have a high amount of weekly/monthly commits as they are being developed). Therefore, this badge would give users a better idea of a project's dependability than weekly/monthly commit counts.
This can be done with the github V4 API e.g:
query {
repository(owner:"badges", name:"shields") {
object(expression:"master") {
... on Commit {
history {
totalCount
}
}
}
}
}
I'm not 100% convinced this is a massively useful thing to put on a badge given it is shown pretty prominently on the landing page of a GH repo
but if someone wants to work on it, lets go with the graphql query :)
Agree with Chris here. I don't have any objections to including the badge, especially since we have other commit related badges already, but I definitely question the use case and rationale in the description.
Specifically, an all-time commit count really should not be viewed as the measure of project health and maintenance status. Case in point, compare the total commit count of the retired/unmaintained request repo against the similar got repo. The way repositories manage commits is also highly variant, with many higher profile projects employing strategies that actually reduce count (squash on merge, requiring contributors to squash PR commits before rebasing, etc.).
No one's claiming that the trending badges in isolation are perfect indicators of any attribute of a project either, just a data point that shows recency.
@calebcartwright, I agree that it's not a great measure of a project's dependability, but if used in conjunction with weekly/monthly commit badges, I think that it paints a better picture of the project's overall health. I think users can generally make better decisions with more information (even if in some instances that information is misleading such as the large number of commits to the request repo).
@chris48s, The number of commits is shown quite prominently when viewing a README on a GitHub repository, but for people viewing a README on another website (NPM package, VS Code Extension, etc.), viewing the total number of commits requires navigating to the GH repo.
Please reopen #6081, I think this is a very useful shield/badge 🙂
I'm not 100% convinced this is a massively useful thing to put on a badge given it is shown pretty prominently on the landing page of a GH repo
Badges are used massively outside GitHub.com (e.g. GitHub Pages), so I don't think that's a very compelling argument.
For other people looking for a solution in the meanwhile, badgen.net helps out here:
# using the popular repo: github.com/EbookFoundation/free-programming-books
[]]
Or adding the GH logo, a green colour and link to the commits page:
[](https://github.com/EbookFoundation/free-programming-books/commits/main?icon=github&color=green)
Badges are used massively outside GitHub.com (e.g. GitHub Pages), so I don't think that's a very compelling argument. Please reopen #6081, I think this is a very useful shield/badge slightly_smiling_face
I'm not really sure what you're trying to argue nor what point you're trying to make, and especially unclear why given the dialog above and particularly in the linked PR. If you read through the discussion on #6081 several things should be rather clear:
- we're more than open to the inclusion of the badge
- there's quite a number of outstanding implementation issues with that PR, which stalled out
Whether an incomplete and abandoned PR that author is unable to work on is in the open or closed state is quite orthogonal at this point. If you or anyone else would like to see this badge within Shields then I'd encourage you to consider picking it up and addressing those unresolved issues (e.g. grab the existing commits via something like git fetch origin pull/6070/head:pr-6070)