What CodeHerder built in this repo

Every connected repository has three read-only views of what’s happened in it: a ledger of every commit CodeHerder’s agents made, the repo’s full merge-request history, and a split showing how much of that history is CodeHerder’s versus everyone else’s.

Open Set up → Repos, then the repo you want, and look below the sessions list. The panels appear in this order: Activity split, Merge requests, then Commit ledger. From the CLI, three commands cover the same ground: ch repo activity, ch repo merge-requests, and ch repo commits.

The commit ledger

The commit ledger is CodeHerder’s own record of every commit its sandboxes made against the repo, branch commits included, newest first. It needs no setup. Every task that commits code adds to it automatically.

ch repo commits my-app

Each row shows the SHA, commit message, author, when it landed, and which sandbox made it. Like other list commands, it takes --limit and --cursor to page through a long history. See Paging through long lists.

The merge-request list

The merge-request list is different. It’s the repo’s full history from your git host, CodeHerder’s own merge requests mixed in with everyone else’s. Each row carries an origin tag, codeherder or external, so you can tell who opened it at a glance.

ch repo merge-requests my-app

Each row shows the merge request’s number, title, source branch, state, origin, and when it happened. It takes --limit and --cursor too.

Unlike the commit ledger, this one needs a git-host integration connected for the repo’s host (see Integrations). Without one, CodeHerder has nowhere to pull the host’s merge-request history from, and the list stays empty.

The activity split

The activity split rolls the same history into one number: what share of this repo’s commits and merge requests are CodeHerder’s, versus everyone else’s.

ch repo activity my-app

The output shows the window it covers, whether a sweep has reached the repo yet, and one line each for commits and merge requests, in the form N codeherder / N external (N% codeherder, N total).

Like the merge-request list, the split needs a git-host integration for the repo’s host. Without one, it still reports as “swept.” It just shows 0% CodeHerder over 0 total on both rows, with an empty merge-request list. Nothing on the page or in the CLI output explains why. If you see an all-zero split on a repo you know has real activity, check whether the repo’s host has a connected integration before assuming something’s broken.

Before the first sweep reaches a repo at all, the split reads “not swept yet” instead. Sweeps run on their own cadence. Check back after the next pass rather than expecting an instant result.

How CodeHerder tells its own work apart

CodeHerder doesn’t guess. It counts a commit as its own when the commit’s SHA appears in that repo’s commit ledger, and it counts a merge request as its own when the request’s source branch is one a CodeHerder sandbox created. Everything else counts as external. This is also why the commit ledger works without any integration: it’s CodeHerder’s own record, not something pulled from the host. The merge-request list and the split need one because both depend on the host’s full history for comparison.

What the window covers

The merge-request list and the activity split both look back 90 days. Anything older than that isn’t included, no matter how it’s sorted or paged.

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 — a plain workspace member below it can use the repo but won’t have access to these three views.

Related guides

• Connecting repositories — register a repo and manage its settings
• Integrations — connect a git-host integration so the merge-request list and split can populate
• Activity feeds — the event-by-event record this repo’s other Activity panel shows