GitLab history is spread across projects. Gitrospective uses the API of the configured GitLab instance, which is GitLab.com by default, and scans the projects available to the connected account.
Which projects are checked?
The importer combines membership projects with the projects returned by GitLab’s contributed-projects endpoint. Duplicate project IDs are removed before the scan. Each saved project keeps its namespace, visibility, archive status and activity dates.
How commits are matched to the account
Gitrospective reads the account email fields and confirmed addresses available through the GitLab API. It asks each project for commits by those authors across all refs, then verifies the returned author email. If the account exposes no email, the importer falls back to the GitLab display name.
Commit matching depends on the author name and email stored in each Git commit.
Merge requests and issues
The importer requests merge requests and issues with the connected user as author. Open and closed items are included. Their creation date is added to the daily count. GitLab review activity is currently absent from the import.
How the GitLab calendar is assembled
Commit author dates, merge request creation dates and issue creation dates are grouped by calendar year. Repository totals are derived from commits. Groups appear in the organization view when a project namespace is a GitLab group.
Known gaps in a GitLab import
The account must still have API access to a project. Deleted projects and revoked memberships disappear from the available set. Commits with an old or unlisted author email can also be missed. A local repository scan may recover dates when a clone still contains the relevant refs.
For comparison, the GitHub importer uses annual contribution collections supplied by GitHub.