Post #1953557

2026-03-28 19:50 UTC

@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

Replies (1)

@lina@vt.social 2026-03-29 03:04

@cas @sbysb Those two flows are not incompatible. You can have sensible commit messages describing individual logical changes, and a PR describing a group of related changes. It's exactly the same as the cover letter model. If your commit messages are essentially worthless and you rely on the PR description to actually describe what is going on, then the solution is to hit the "squash" button instead of the "merge" button and promote the PR description to a single commit message. I think that once you're collaborating with others, a messy commit history has negative value. The tiny commits are useful ephemerally during development, but not as a historical record. It's better to have larger commits with good documentation than it is to have meandering small commits which hardly make sense on their own. Just squash. That's also very important because PR descriptions are often lost. You don't want important information about code history to exist only in the forge database. Squashing also makes rebasing and pulling patches out easier, especially if the development process involved trying and redoing things to any extent. Having commits that revert portions of each other in the history is actively harmful in this case. Essentially, if your PR model involves reviewing the "global changes" view, you want to squash. If you review individual commits, you don't.

Open ##1953558