NEW FEATURE: Optional daily commit graph (including non-default branches) #267

Is your feature request related to a problem? Please describe.
I came across this project while customizing my GitHub README and thought it would be useful to have an option to display daily commits separately from GitHub's contribution counts.

I think this could be especially helpful for developers working on personal projects, learning, or building features on branches that haven't been merged yet.

The current graph uses GitHub's contribution calendar, which doesn't necessarily reflect every commit made in a repository.

Describe the solution you'd like
I'd like to propose an optional metric=commits parameter that would:

Display daily commits instead of contribution counts.

Include commits from non-default branches.

Avoid counting the same commit more than once per repository.

Preserve the existing graph as the default behavior.

Reuse the existing themes and customization options.

For example:

/graph?username=example&metric=commits

The exact parameter name and repository selection behavior would be open for discussion.

Proof of concept

I created a small, isolated TypeScript PoC using GitHub's REST API to check whether this would be feasible.

I was able to verify a case in robertpierson/click-speed-test on August 7, 2026:

Default branch: 4 commits

All branches (SHA-deduplicated): 5 commits

Additional commit found: 72ac456d, on robertpierson-patch-1

The PoC successfully detected the additional commit without double-counting it.

Limitations

The main concern is API usage. In a separate 32-day test, fetching commits across seven repositories required 53 REST API requests.

For a public service, I think this would require caching, request limits, and possibly an initial scope limited to selected public repositories.

Private repositories and their authorization requirements could be handled separately.

Describe alternatives you've considered
Counting only default-branch commits would be simpler, but it wouldn't fully address the original use case.

Additional context
I noticed the related issue #220 about commits in forked repositories. This proposal is slightly different because it focuses on an optional commit-only metric across branches.

Would you be open to something like this? I'd be happy to work on a PR if it fits the project's direction!