cerved

I wouldn't call it a core feature -- more like a convenience hack.

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