Post #1953556

2026-03-28 19:26 UTC

@cas I think for most of the git as a service websites that would mean you still would end up with a timeline of 'fix' 'fix 2' 'linting' 'fix again' with the description of what actually changed hidden. The value of my commit messages is already about zero as it stands if I am writing them, mostly because I can't stand writing commit messages. A lot of this comes down to how you use git - I might have 30 commit messages in a PR, because I commit and push religiously on basically any change. In my experience Claude is 100% correct when writing a commit message for these small changes so the average value of a commit message on my projects has skyrocketed. On the flip side I have played around with having Claude create the PR itself and am frequently disappointed in how it describes the change. I think what you are describing is actually essentially how it works in my flow: I hand write the PR title and description, and if you wanna look at a summary of what was done specifically there is a whole timeline of very detailed commit messages

Replies (1)

@cas@social.treehouse.systems 2026-03-28 19:50

@sbysb yeah idk, i generally subscribe to the kernel/uboot workflow where you prepare patches carefully and actually have to write good commit messages. I make heavy use of git absorb and manual commit --fixup to make improvements to a patch series so it encompasses sensible changes from the context of the codebase rather than representing a timeline of changes from the context of the developer (which generally has a lot of unnecessary context and is missing more important context) overall making code harder to understand thats the mindset from where im speaking anyway, if you don't care about the quality of individual commits in the same way then whether they're human or AI written becomes quite a different question

Open ##1953557