Reading the history

The code tells you what a program does today. It rarely tells you why it does it that way, what was tried first, or who argued against it. That record lives in the history, meaning the commits, the pull requests behind them, and the review comments on those pull requests.

When you work alone, you remember your own reasons, so history feels like a backup. On a team it is the main way people learn from each other. This chapter reads T3 Code’s history at commit e1fad19 to show how the maintainers name changes, who does the work, how fast it lands, and how they review and say no. Then it gives you a method you can use on any repo, including your own.

A commit subject says what changed for the user

Here is the most recent commit at the pinned point:

$ git log -1 --format='%an %ad%n%s' --date=short 7a39060072
Julius Marminge 2026-11-12
fix(server): a damaged state database fails startup with its path and how to recover (#35057)

The subject has three parts. fix is the type of change. server is the scope, the part of the repo it touches. The rest is a sentence about the outcome. It does not say “wrap PRAGMA calls in Effect.try”, which is how the code changed. It says what a user now sees when their database is damaged. The (#35057) at the end is the pull request number that GitHub adds when it squashes a pull request into one commit.

This format is called Conventional Commits. T3 Code’s agent instructions ask for it in one line:

- Conventional commit titles, plain language: `fix(web): new threads no longer spike CPU`.

The example in that rule is also an outcome, “new threads no longer spike CPU”. Other subjects in the log follow the same shape. fix(server): telemetry keeps a failed batch for 30 minutes, not 1.5 (#25474) gives the old and new numbers. ci(release): scheduled nightly checks read 10 KB instead of 28 MB (#33141) gives a measurement.

The convention arrived later

The repo did not start this way. The first commits, on Feb 7, 2026, are Theo’s, and they read like a solo project. In order, they are Monorepo electron init, ugh, and more testing to prevent issues. Counting subjects that match type(scope): by month shows when the habit took hold:

The line in AGENTS.md was added in Theo’s PR #4782, “docs: overhaul agent guidance”, merged on Jul 28. August is the first month where nearly every subject follows the format. This suggests that once the rule was in the file that agents read, agents followed it. Most commits now list an AI model as co-author, as the next section shows.

The pull request is the record

Of the 10,537 commits that are not merges, 9,402 end with a pull request number. Only 15 commits in the whole history are merge commits, so the team squashes almost every pull request into a single commit. Commit bodies are nearly empty. Since Oct 1, only 96 of 6,007 commits have any body text besides Co-authored-by trailers. The agent instructions say where the detail goes instead. “A merged PR is the implementation record” (AGENTS.md). Because every commit names its pull request, you can almost always get from a line of code to the discussion in one step.

Who does the work, and how fast

git shortlog -sn --no-merges counts commits per author name:

$ git shortlog -sn --no-merges HEAD | head -5
  4404	Julius Marminge
  1131	Theo Browne
   553	maria
   254	Alex Southwell
   243	Victor Vogel

There are 985 distinct author names in all. Some people appear under more than one email. git shortlog -sne shows Julius under four name and email pairs, for example. The counts above group by name, so they already merge most of those.

The pace has grown fast. The repo had 94 commits in May 2026 and 4,236 in October. Over the 30 days ending Nov 11 (by author date), the median day had about 130 commits, the quietest had 40, and the busiest, Oct 20, had 401. That pace is why Theo’s PR #10410 changed stable releases to ship the last nightly build. Its description says “We merge hundreds of PRs a day.”

Releases follow the same rhythm. At the pinned commit there are 692 nightly tags and 51 stable tags. Each stable tag points at the same commit as a nightly tag, because stable releases promote a nightly that users already ran.

The trailers show how the work gets done. Since Oct 1, 3,568 of the 6,007 commits list a Claude or GPT model in a Co-authored-by trailer. Claude Opus 5.5 alone appears on 2,942 of them. The pull request bodies say the same thing in their last line, such as “Created with GPT-6 Astra in Codex.” in PR #10272. Most changes are written by agents that a person directs, and the person’s name goes on the commit.

How they describe, review, and say no

Describing a change

PR #35057, opened from Julius’s account, shows the full shape. The body starts with the root cause and names the function where the error escaped. It then has a “Reproduction on main” section with the exact command, an evidence table with before and after screenshots of the real CLI output, and a “Tests” section that says the new test “failed before the fix”. It ends with a “Not in this change” list, which names three related problems the fix leaves alone. That last list matters for a reviewer. It says where the edges are, so nobody assumes the change covers more than it does.

The project’s contributing guide asks the same of outside contributors in two rules. The first is “Fix one problem.” The second is about evidence. It says that “Tests pass” is not evidence.

Pushing back on a design

One clear human review is Julius’s on PR #1732, a contributor’s change to show provider usage limits. The review starts “implementation seems way overcomplicated.” Julius then asks “why cache the data? the provider check runs once per minute,” and writes out the expected design in four steps. Extend the existing provider check, read usage during the auth probe, send it with the normal provider snapshot, and render it in settings. The review ends with “why is this PR so much more than that?”

The same thread shows the team disagreeing in public. In August, a comment from Theo’s account closed the PR in favor of Theo’s own proposal. The comment is labelled “GPT-5.6 Sol responding on behalf of Theo”. Julius replied in support of the contributor’s version, adding that “his agent might have been a bit of a yes-man”. Theo answered “My bad”. The usage limits feature later landed in PR #9507, which Julius’s closing comment says was “distilled from this PR’s server model”.

Saying no to size

In August and September the maintainers swept the backlog of open pull requests with agents. The closing comments name size as the reason, in numbers. PR #6315 was “a 40,000-line patch”. PR #8014 added “more than 16,000 lines across 79 files”. PR #6316 changed the project model “across 184 files”. Each of those comments was posted from Theo’s account with an agent banner, so the words are the agent’s, and the decision is Theo’s to stand behind.

A closed pull request is not always a lost idea. On #6315, a later comment from Julius’s account thanked the contributor for mapping each issue tracker’s quirks and linked a stack of smaller pull requests, starting with #19259, built “with your PR as the reference”. On PR #6436, Julius wrote that the contributor “found the right root cause” and that the fix had been carried onto current main in #9325, because the branch was “61 commits behind”.

Reading who wrote what

Many comments under Theo’s and Julius’s accounts start with a note such as “Claude Opus 5.5 responding on behalf of Theo” or “This comment is posted by Julius’ dot”. The account tells you who is responsible. The note tells you who wrote the words. Read the first lines of a comment before you quote it as someone’s opinion. The labelling convention is also worth copying. If an agent writes in your name, say so.

A method for reading any repo’s history

You need four commands. Each answers a different question.

A worked example

The telemetry sender in T3 Code has this line, and the number looks arbitrary:

const MAX_BATCH_RETRY_MS = 30 * 60_000;

Start with blame:

$ git blame -L 51,51 apps/server/src/telemetry/AnalyticsService.ts
576a40fa53 (Theo Browne 2026-10-26 16:05:43 -0700 51) const MAX_BATCH_RETRY_MS = 30 * 60_000;

The commit subject is fix(server): telemetry keeps a failed batch for 30 minutes, not 1.5 (#25474), so the pull request is #25474. If a commit has no number, gh pr list --search <sha> --state merged finds the pull request that contains it. Open it:

$ gh pr view 25474 -R pingdotgg/t3code --comments

PR #25474 answers the question. The old code gave up after five tries, about 1.5 minutes. On Oct 25, 2026, one Cloudflare location failed every request for 5 minutes, and “about 160 events were lost”. The pull request also lists the tests that prove the new window, two of which the description says fail on main. The line now has a reason, a date, and a measured cost.

git log --follow gives the wider view. For .github/scripts/check-nightly-release.cjs it lists five commits. Apart from one comment cleanup, they tell the story. Theo added the six-hour gap between nightlies in PR #10272, made stable releases build from the latest nightly in PR #10410, and later made the scheduled check read 10 KB instead of 28 MB. Julius restricted stable releases to main in between. The subjects alone tell you how the file grew before you read a line of it.

Habits that make this work

• Read the pull request, not only the diff. The diff shows the change. The description and review show the options that were turned down.
• Read closed pull requests too. A closing comment is often the clearest statement of what the project does not want.
• Check who wrote a comment before you quote it, as the section above explains.
• Write down what you learn in your own words. A reason you can explain is one you can reuse.

Your history next to theirs

Commit subjects

In monosodiums, 45 of 57 non-merge commits use the type(scope): outcome format, such as perf(island): compile shaders before the first frame (#16). Your subjects describe what a visitor sees, like fix(island): keep the sand pale under the moon, which is the T3 Code style. The exceptions are at the start. Ten early commits are all Update Site source, which tells a future reader nothing.

fud shows the same switch later. Only 14 of its 49 commits use the format, starting with feat(mobile): add Direct Inbox navigation (#13) on Oct 28. The earlier subjects, such as Send a Web Push Alert when the month runs far above usual, are plain sentences without a type. They still describe the outcome, which is the more important half of the rule.

Pull requests

Your pull request bodies are strong. monosodiums PR #16 has sections named Why, What changed, Scope, Tradeoffs, Blast Radius, and Verification. It gives measured numbers (“1557 ms → 992 ms in light mode”), says what it did not measure (“Windows and phones are not measured”), and lists ideas it tried and dropped. That matches the “Not in this change” habit in T3 Code’s PR #35057.

Two things differ. First, the monosodiums pull requests have no comments or reviews at all. fud has review verdicts posted from your own account, such as three rounds of FAIL, FAIL, then PASS on PR #21. Those reviews are the closest thing you have to Julius’s review on #1732. Keeping them on the pull request, as you do in fud, means the reasoning survives.

Second, the merge method is mixed. Pull requests #1 through #22 in monosodiums were squashed, but #23 and #24 were merged with merge commits. The 22 commits inside #24 carry no pull request number. The last commit to touch src/world/lighting.js is f7b7615, and you need an extra gh pr list --search f7b7615 to learn it came from #24. T3 Code avoids that step by squashing almost everything.

Identities

git shortlog -sne in monosodiums lists three authors: MK with a GitHub noreply address, Mona Kecil, and Mona-kecil. They are all you. T3 Code has the same problem, with Julius under four name and email pairs, and it has no .mailmap to fix it. In a solo repo it matters less, but it does split your own counts.

What not to copy

The backlog sweeps, the agent comment banners, and the review bots exist because T3 Code merges hundreds of pull requests a day and receives many from people outside the team. A solo repo does not need a closing policy. It does benefit from the cheap parts. Those are outcome subjects, one squashed commit per pull request, and a description that says what you left out.

Try it

1. Trace a line in your own repo. In monosodiums, run git blame public/_headers. It points at commit 0afaef5. Run gh pr view 16 -R Mona-kecil/monosodiums and find the paragraph that explains why /assets/* gets a one-year immutable cache, and the warning about hashed file names. Then do the same for line 249 of fud/worker/index.ts. Blame points at 2ed8d4a, which belongs to PR #11. Write one sentence on whether that pull request explains the fixed log string. If it does not, you have found a reason that only lives in your head.
2. Squash every pull request. In the GitHub settings for Mona-kecil/monosodiums and Mona-kecil/fud, under Pull Requests, allow only squash merging, and set the default commit message to the pull request title. Your next merge should produce one commit whose subject ends in (#<number>). Check with git log -1 --format=%s after you pull.
3. Merge your identities. Add a .mailmap file at the root of monosodiums with two lines. The first, Mona Kecil <your-email>, gives every commit from your personal address one name. The second, Mona Kecil <your-email> <67728698+Mona-kecil@users.noreply.github.com>, maps the GitHub noreply address onto it. Put your real address where it says your-email. Run git shortlog -sne HEAD. It should show a single author with all 59 commits.