Public

Exploring Aggregated Stats Across Multiple RepositoriesPublic

The user wanted to explore using a new tool to collect and combine data from multiple code repositories. Their goal was to generate overall statistics and insights at an organizational level rather than just individual projects. This approach aimed to provide a broader view of activity across all repositories within the organization.

Agent

Claude Code

Model

Claude Opus 3

Shared

Feb 6, 5:11 PM

Messages71

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

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

Listed/Users/andrew/code/git-pkgs/*

Ran sub-agentExplore git-pkgs codebase

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

Readforges.go

Readtypes.go

Listed/Users/andrew/code/git-pkgs/forges/*.go

Readstats.go

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

Readgithub.go

Readroadmap.md

Readstats.go

GreppedListRepo|FetchOrg|ListOrg|org|organization

Listed/Users/andrew/code/git-pkgs/git-pkgs/internal/database/*.go

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

Greppedtype Stats struct|type AuthorStats|type StatsOptions|type NameCount

Greppedfunc.*GetStats|func.*GetAuthorStats

Readgo.mod

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:

Used AskUserQuestion

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.

Used EnterPlanMode

Ran sub-agentExplore forges module patterns

Ran sub-agentExplore git-pkgs CLI structure

Now let me design the implementation.

Ran sub-agentDesign orgs implementation plan

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

Readqueries.go80 lines

Readschema.go

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

GreppedSchemaVersion\s*=

Now let me write the plan.

Used ExitPlanMode