News for hackers. Stuff that matters.

cerved

I wouldn't call it a core feature -- more like a convenience hack.
Re:Commit description as a thinking tool on Thursday October 01, 2026 @02:35AM (#49918400)
The latest batch of models have noticeably improved. But Opus 5.1 was peak claudeish
Re:Commit description as a thinking tool on Wednesday September 30, 2026 @03:33PM (#49913252)
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!
Re:Commit description as a thinking tool on Wednesday September 30, 2026 @03:31PM (#49913235)
I like the Git rule of thumb. If it's too long -- it's probably not a single commit.
Re:Commit description as a thinking tool on Wednesday September 30, 2026 @03:29PM (#49913216)
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.

Re:Commit description as a thinking tool on Wednesday September 30, 2026 @02:47PM (#49912773)
why not both? notes are pretty ephemeral by design
Re:Commit description as a thinking tool on Wednesday September 30, 2026 @02:41PM (#49912692)
If you ask an LLM to write a message that explains "the why", it'll make up a why.
Re:Stop Making TUIs on Saturday August 22, 2026 @10:42AM (#49400280)
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.

Re:Staging patches with Git add -p on Wednesday July 29, 2026 @06:05PM (#49103683)
Vin fugitives difftool is even better

Also, you can use -p for stash push

Re:Git rebase -I is not that scary on Sunday July 26, 2026 @06:08AM (#49056490)
You dont need to open the reflog you can just

    git reset --hard @{1}
After a rebase to "undo" it.
Re:Local Git Remotes on Sunday May 31, 2026 @03:20PM (#48348797)
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
Re:Local Git Remotes on Sunday May 31, 2026 @10:00AM (#48345744)
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

Re:Local Git Remotes on Sunday May 31, 2026 @09:29AM (#48345536)
Doesn't work. You need to mount both the worktree and the repo which defeats the point
Re:Local Git Remotes on Friday May 29, 2026 @09:46AM (#48323058)
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)

Re:Stop Advertising in Your Commits on Tuesday May 26, 2026 @04:00PM (#48285204)
Fwiw you can create your own trailers

    Yolo-Slopped-By: Sonnet-4.5 <[email protected]>
https://git-scm.com/docs/git-interpret-trailers
Re:If AI writes your code, why use Python? on Tuesday May 12, 2026 @11:19AM (#48109612)
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
Re:GitHub CLI now collects pseudoanonymous telemetry on Wednesday April 22, 2026 @09:27AM (#47863309)
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
Re:A forecast of the fair market value of SpaceX's businesses on Wednesday April 15, 2026 @08:47AM (#47778272)
> 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
Re:A Coherent Vision for the Future of Version Control on Thursday April 02, 2026 @02:26PM (#47618254)
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?
Re:A Coherent Vision for the Future of Version Control on Sunday March 22, 2026 @06:49PM (#47483118)
Tip, you may want to use origin/HEAD over origin/master
Re:A Coherent Vision for the Future of Version Control on Sunday March 22, 2026 @06:43PM (#47483046)
It does
Re:Autoresearch for SAT Solvers on Thursday March 19, 2026 @02:22AM (#47435637)
Would me be nice to try this on lcg (CP-SAT) solvers
Is the a b test tired to the installation or the user?
Re:Don't make me talk to your chatbot on Tuesday March 03, 2026 @06:42PM (#47240785)
I instruct Claude to write like peff, writes much better commit messages now
Re:Microsoft forced me to switch to Linux on Wednesday January 28, 2026 @06:07PM (#46803020)
If only the streaming giants would let us stream in decent quality..

Older ยป