Comment by kilpikaarna
Comment by kilpikaarna 14 hours ago
Keeping it real with the commit msgs
Comment by kilpikaarna 14 hours ago
Keeping it real with the commit msgs
https://github.com/oliverbenns/john-carmack-plan you can read carmacks old .plan files
They're mostly not exactly prose but remember this was almost 40 years ago when the dominant style of writing code in some places was still ye olde K&R C with one letter variable names and goto everywhere
I was appreciative/shitposting.
Would love to see Carmack's commit messages. Just the other day I unsuccessfully tried to look for pictures of his office newer than QuakeIII era. Want ti figure out his ergonomics for working (presumed) 10h days well into middle age.
I much prefer this over those AI generated commit messages that just say "refactored X" every single commit.
what kind of AI are you using that generates shitty commit messages? This a common kind of message from Claude / Augment:
Fix dynamic channel list by passing auth via metadata
- Pass userId and userEmail in metadata when calling HTTP transport
- AuthenticatedToolsProviderFactory now reads from context.metadata
- Each tools/list request creates a fresh ToolsProvider with authentication
- Execute command description now correctly shows currently online machines
- Tested locally and working correctlyGod I can't stand it when I get this kind of output from Claude, they really need to train it out for Claude 5.
"[Tangentially related emoji] I have completed this fully functional addition to the project that is now working perfectly! There are now zero bugs and the system is ready for deployment to production! [Rocketship emoji]"
Then of course you test it out and it doesn't work at all! It's very grating. It would be more bearable if it hedged its claims a bit more (maybe that will negatively affect the quality of the results though - if training a model to output insecure code also makes it a murderous Hitler admirer then, since when humans hedge their output is less likely to be perfect, it may mean it pushes the model to output code that is less than perfect).
> "[Tangentially related emoji] I have completed this fully functional addition to the project that is now working perfectly! There are now zero bugs and the system is ready for deployment to production! [Rocketship emoji]"
This made me laugh so hard. Never trust an AI model saying “There are now zero bugs”! Weaponized incompetence? :)
As a side note, I absolutely am in love with GPT-5 and GPT-5-codex. When I talk to it, it feels like talking to a peer and not an over enthusiastic (but talented) junior with potential. GPT-5-codex on high has been exceptional at debugging insidious bugs.
And there's at least an 80% chance one of those items is, in fact, not in the commit.
It is missing the (to me) most important part. The reason why these changes are made.
Set a PR template up, that demands those sections are filled in. Could probably do that down to the commit level with pre-commit but realistically you'd want that level of detail in the in the PR. Also add issue id to the commits too, that way you can pull them up easily and get more context.
True, you need to instruct the AI agents to include this.
In our case the agent has access to Jira and has wider knowledge. For commit messages i don’t bother that much anymore (i realise typing this), but for the MRs I do. Here i have to instruct it to remove implementation details.
GitHub Copilot for one, and I'm pretty sure JetBrains' offering does the same.
Every time I’ve tried to use AI for commit messages its designers couldn’t be bothered to get it to take into account previous commit messages.
I use conventional commit formats for a reason, and the AI can’t even attempt it. I’m not even sure I’d trust it to get the right designation, like “fix(foo)!: increase container size”.
They probably didn’t care. And having many small commits instead of a big squashed one can be useful when using git bisect for example.
I like `tig blame` for this. It has a key (comma, maybe?) that pops back to the file just before the change on the highlighted line so you can quickly work your way backwards through non-changes like you describe. It doesn’t deal with renames well, though.
Some criticism of the author here regarding how they structure their diffs.
They "made something ~100 tflops faster" and peoples' comments are "their commit messages are bad"? You guys would hate how John Carmack worked, too