Hosting providers can only return repositories that still exist and remain accessible. Old clones on your computer may contain prototypes, migrated projects and private client work that no profile graph shows.
Why scan local Git history?
Git stores commits inside each repository. If a branch, tag or remote ref still reaches a commit, the scanner can read its author and date even when the original hosting account has changed.
What can be learned from Git metadata?
The scanner reads these fields:
- the project or repository name;
- normalized remote URLs, when present;
- commit author identities used for matching;
- commit dates and daily counts;
- the first and last day of visible activity.
They are enough to count your commits by project and date.
Data sent by the CLI
The Gitrospective CLI sends project names, normalized remote URLs, dates and commit counts. Source files and commit messages remain on the computer. The CLI stores its credential in the operating system’s secure credential facility when one is available.
The server receives daily counts and project metadata. It never receives a repository copy.
How are your commits identified?
A shared repository contains work from many people. The scanner matches commits to the
connected profile and local Git identities, including configured email addresses,
.mailmap mappings and recognized provider noreply addresses. Additional
historical emails can be supplied when an old identity is missing.
What happens to repositories already on GitHub or GitLab?
Gitrospective compares normalized remote URLs with the repositories imported from GitHub and GitLab. A matching local clone is excluded from the combined total. Repositories with no cloud match remain visible.
See how every source is reconciled, or start with the limits of GitHub contribution history.