cerved

The latest batch of models have noticeably improved. But Opus 5.1 was peak claudeish

There's pretty much always several plausible reasons for why a change was made. What's interesting is knowing exactly which one, especially when it later turns out to be wrong!

I like the Git rule of thumb. If it's too long -- it's probably not a single commit.

Claude tends to just narrate the change when it writes the commit message. Which is not very interesting. Anyone can read the diff and figure out _what_ it does. The interesting is why.

So I've been instructing Claude to commit like Jeff King.

At first, Claude would mainly just cosplay Peff. Emulate the prose and not the process. Over the last few months I've been iterating on it and now Claude writes vastly better commit message than by default.

Initially, Claude would produce A LOT of plausible sounding reasons the LLM "thought" made sense. Instruct an LLM to give reason and it'll give you reasons -- whether they are real or not. After trying to instruct it not to lie, make shit up etc (which did not work) I instead started forcing it to articulate the source of the rationales. Especially which claims where unsubstantiated, and this seems to have helped a lot.

Then I instructed it to do some thorough investigation before it commits.

Start by writing a brief that gathers different "evidence" that underpins a change. The diff itself. The surrounding context. A bit short git log. A blame on the touched lines to see what previous commits touched this code and for what reasons.

Once it's done the agent has to tag each claim according to a category. I.e. what claims are attributed to the change itself (the diff), the inciting incident (gathered from session or if missing, by follow-up questions), what's inferred by the model (unsubstantiated claims.)

Only after this supersize is it tasked with writing a commit message given this brief. Or to ask follow-up questions if there's only unsubstantiated claims or gaps in the brief. Furthermore, it is tasked with writing a note to detail assumptions it has made and, or other relevant bits of information that are not commit message worthy, but possibly still interested in noting down. Decisions made. Options not taken. Possible rationales for the change that didn't make the cut.

All of this tends to make pretty good commit messages. Not perfect, but a good starting point.

Right now my biggest challenge is finding instructions to write the Goldilocks message. Not too brief and not too long. Instruct it to be clear and concise and relevant information gets left out. Say nothing and get a Dostoevsky novel. At least when it writes too long messages it's easy enough to go in afterwards with a `git history reword` and take out the axe.

One of the biggest upsides has been, just as when you read a human that writes commit messages like this, is spotting misunderstandings. Several times I've spotted gaps in the reasoning of the message that doesn't match reality, and caught mistakes. A bit like when you use plan mode.

why not both? notes are pretty ephemeral by design

If you ask an LLM to write a message that explains "the why", it'll make up a why.

The advantage is that you can run it in a terminal... So in tmux, over ssh, etc.

My theory is it writes these comments as "notes while working", and I don't don't mind that, per-se. My problem is it's inability to clean that shit up before committing it. That's wrong load-bearing lever that doesn't earn it's keep.

Also, it reads like ass.

I'm becoming increasingly allergic to the performative writing of LLMs.

The worst part is how compulsive LLMs are at writing like this. Like the system prompt instructs it to "reason" and like a college Sophomore it pontificates and quotes Nietzsche to fein intelligence and orginal thought.

Vin fugitives difftool is even better

Also, you can use -p for stash push

You dont need to open the reflog you can just

    git reset --hard @{1}

After a rebase to "undo" it.

ofc if you're running AI agents in YOLO mode — clones means you don't need to worry that Sonnet is going to see your .git/index.lock file and go "this is blocking me, let's rm -f this" and corrupt all your work that you never bothered pushing

Worktrees effectively share the entire state of the repo. Only limitation is that a branch can only be checked out in one repo at a time.

Clones only share the immutable object store

For most practical uses of same repo checking out different branches locally, worktrees are better.

The nice thing about clones is that you can have a backup clone, a wip clone, a review clone where you don't clutter the amount of local branch refs

Doesn't work. You need to mount both the worktree and the repo which defeats the point

you can also setup a local remote which hardlinks the index so it doesn't occupy more space. Why? Idk. You don't want to share stash, rerere-cache, branches whatever.

Also handy if you're running an agent in a container on the local fs. Set up a local clone, contain the agent to that repo folder and have it hack away on that. Later, you step out of the container and do the syncing. You can't use worktrees in this situations.

Bare repos are also pretty cool. You can clone the git mailing list as a bare repo and search for threads there instead of setting up an mbox (same for the kernel obviously)

Fwiw you can create your own trailers

    Yolo-Slopped-By: Sonnet-4.5 <claude@anthropic.com>

https://git-scm.com/docs/git-interpret-trailers

if you want to reason about language correctness you are better off using linters, compilers and things like fuzzing

> the trend is AI also does the code review

please no. Keep at least four eyes on all code you ship

Anthropic obviously vibe code everything and it shows

You use gh to interact with the forge, git to interact with the repo.

For example

  gh pr checks --watch

will run and poll the CI checks of a PR and exit 0 once they all pass

> Starlink Consumer Broadband at $380B (9.2M subscribers, ~38x revenue)

I mean that Starlinks consumer broadband is valued at ~38x revenue, when other telcos are valued around 1.5x revenue. That revenue is 2533% more expensive, why pay such a big premium for something that's essentially the same?

Anthropic should run it on their own code

not strictly speaking, but in practice it's the tip of the remote default branch

For $380B you can get both AT&T and Verizon and you pay ~1.55x the revenue. Why pay 38x for Starlink?

Tip, you may want to use origin/HEAD over origin/master

It does

Would me be nice to try this on lcg (CP-SAT) solvers

Is the a b test tired to the installation or the user?

I instruct Claude to write like peff, writes much better commit messages now

If only the streaming giants would let us stream in decent quality..

So it does a forced reset of the dirt after each bash command? Does it confuse Claude? I frequently find it lacks path awareness of what it's working directory is