Exploring Aggregated Stats Across Multiple RepositoriesPublic

Agent

Claude Code

Model

Claude Opus 3

Shared

Feb 6, 5:11 PM

Messages71

Downloads23

Summary

I'd like to investigate using the new forges module as a way to drive git-pkgs to aggregate stats from across multiple repos, to give similar insights but at an "org" level

Good overview. Let me look at the forges API more closely and the stats command to understand the building blocks.

Let me check if forges already has org-level listing, and look at the GitHub backend and the roadmap.

Let me start by understanding what's in this repo and what git-pkgs/forges looks like.

Let me check the Stats types and the database query structure.

Now I have a clear picture. Here's what I found and where I see this going.

Current state of forges: The module fetches metadata for individual repos (FetchRepository, FetchTags) across GitHub, GitLab, Gitea/Forgejo, and Bitbucket. It has no org-level listing -- it doesn't know how to enumerate repos for an owner/org. But the underlying SDKs (go-github, gitea/sdk, gitlab client-go) all support listing org repos.

The gap: There's no way to go from "give me an org name" to "here are all the repos and their aggregated dependency data." The orgs/ directory is empty, and git-pkgs is entirely per-repo today -- one SQLite database per repository.

What forges would need to add: A ListRepositories(ctx, owner) method on the Forge interface (or a separate OrgForge interface to avoid breaking existing implementations). Each backend would page through the forge API and return []Repository.

What the orgs module could then do:

Call forges.ListRepositories to get all repos for an org
Clone (shallow) or open each repo locally
Run git-pkgs indexing per repo (or read existing databases if already indexed)
Aggregate into org-level views

The interesting org-level insights, pulling from the roadmap and the existing stats structure:

Shared dependencies -- which packages appear across multiple repos, and at what versions
"Which repos use package X" -- the inverse query, already called out in the roadmap
Vulnerability exposure -- how many repos are affected by a given CVE
License compliance -- org-wide license inventory, flag repos with problematic licenses
Ecosystem breakdown -- how many npm vs gem vs pypi dependencies org-wide
Staleness -- which repos have the most outdated deps
Dependency churn -- which repos have the most dependency activity

A few design questions before going further:

Good, that's clear. Two workstreams: extend forges with org listing, then build the orgs CLI here that drives git-pkgs across repos.

Let me plan the implementation.

Now let me design the implementation.

Let me verify a few details about the pkgs database schema and the dependency query before finalizing the plan.

Good. I have everything I need. Let me also check one thing -- the SchemaVersion constant.

Now let me write the plan.