Tracking codebase size

CodeHerder measures your codebase’s size: production lines, test lines, and how the two compare over time. The web app has two views onto this — one for your whole workspace, one for a single repo — and the CLI covers both, plus two dimensions the web app doesn’t chart. This page walks through all of it, and explains what “not measured” means along the way.

The workspace rollup, at the bottom of Repositories

Open Repositories in the sidebar, under Set up. Above the repo list, a Snapshot timestamp for the most recent measurement and a Coverage line show how many of your repos have been measured at least once, out of how many are registered.

Below the repo list, the workspace-wide rollup follows: every repo your workspace can see, rolled into one set of figures. Four tiles summarize the selected range, each with a small trend line:

• Production LOC — lines in your application code, with the file count and net change alongside.
• Test LOC — lines in your test code, the same way.
• Test/production ratio — how much test code you have relative to production code.
• Net change over range — the overall line count change, split into production and test.

A range control offers 7, 30, 90, or 180 days, all time, or a custom date pair. An Export CSV button downloads the selected range as a spreadsheet. Two charts follow the tiles: History, which charts daily production and test line counts for the selected range, and Daily movement, which charts additions minus removals per day so you can spot which days changed the most code. Both views chart production and test lines only — for comment and documentation lines, use the CLI below.

Under the charts, Where the lines live splits the latest snapshot by repo, production and test lines each, and each row links through to that repo. To see one repo’s own figures, open its row — see the next section.

If your workspace has no repos registered yet, the page says so: “No repos are registered in this workspace yet.” Register one to start tracking its production and test line counts. If it has repos but none of them have been measured yet, it says: “No repo in this workspace has been measured yet. A device measures each registered repo’s production and test line counts on its own cadence.”

A repo’s own codebase sections

Open Set up → Repositories, then click a repo. Its codebase sections — History, Daily movement, and Where the lines live — sit at the top of the page, listed in the “on this page” rail alongside its other sections.

Above the charts, a caption line shows the branch CodeHerder measured against, the snapshot timestamp for the last measurement, and how many days of history are on record.

The same four tiles, range control, Export CSV button, and History and Daily movement charts described above appear here too, scoped to this one repo. Where the lines live splits the latest snapshot by area of the codebase instead of by repo, production and test lines each.

If the repo hasn’t been measured yet, the page says so: “This repo has never been measured. A device measures its production and test line counts on its next sweep.” Give it time — measurements aren’t triggered on demand.

From the command line

ch repo loc my-app

This prints the repo’s latest snapshot: branch, commit, and when it was measured. It also shows production, test, comment, and documentation line counts, plus the test/production ratio. It ends with how many days of history are on record. A per-area breakdown follows, the same split as “Where the lines live” on the repo’s own page.

Add --history for the daily series instead of just the latest snapshot:

ch repo loc my-app --history --since 30d

This prints one row per day, with each dimension’s count and its net change. Each row also shows the ratio and whether that day was truncated (see below). --since and --until bound the window; leave both off and you get the full history CodeHerder has retained.

Across your whole workspace

ch workspace loc rolls every repo in your workspace into one view — the same figures the workspace rollup at the bottom of Repositories shows, plus comment and documentation lines, which that rollup doesn’t chart.

ch workspace loc

This shows how many repos are visible versus measured, then the combined totals and ratio. A breakdown per repo follows — at workspace scope, lines break down by repo, not by area.

Add --history for the same daily series, aggregated across every repo:

ch workspace loc --history --since 30d

Leave --since and --until off here too and you get the full retained history. If one of your repos misses a day’s measurement, its last known value carries forward into that day’s total instead of dropping out — so a single missed measurement never makes your workspace total dip.

ch workspace loc defaults to your active workspace. Pass a workspace name or ID to check a different one.

How measurement works

A device measures a repo’s line counts, at most once a day per repo. CodeHerder picks an available device connected to the repo’s workspace — no setup needed.

A few terms are worth knowing:

• Never measured means CodeHerder has no snapshot for this repo yet.
• Not measured, next to a figure like comment or documentation lines, means that dimension wasn’t captured for that day. It’s different from an actual count of zero.
• Truncated marks a day whose measurement hit a size cap partway through, so its counts are a partial picture.

Who can see this

Anyone who’s a member of the workspace that owns the repo. If the repo is inherited from a parent group, that means membership in the group itself.

Related guides

• What CodeHerder built in this repo — commits and merge requests for a repo, alongside its line counts
• Connecting repositories — register and manage the repos CodeHerder measures