3 ms·
Fully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or im
by freedomben 1y ago
Fully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or implementing one feature. Obviously there are cases where this ideal isn't practical, but the answer is still not squash everything, it's to think for 10 more seconds about the commit and do your best.
- bavent 1y agoYeah, I think over use of GitHub, which seems to encourage squash-merging, has led to this where a lot of people I’ve seen treat a PR as essentially one commit - because it ends up being one in the end. If you keep your PRs small I guess the end result is the same, but even then I like things in individual commits for ease of review.
- danielbln 1y agoI want to see detailed atomic commits during PR review, and once it's reviewed I'm happy to have it squashed. If the PR produces so much code/changes that main branch needs detailed atomic commits for future reference, then the PR was too large to begin with, imo.
- bavent 1y agoI do agree that this is a good compromise. For me, if I do a git blame and eventually can find the PR that led to change, if it has nice clean commits, that’s good enough.
- focom 1y ago> If you keep your PRs small Its not a if. it's necessary for the sake of people reviewing your code. Unless you work alone on your pet project and always push to master you never work alone.
- bavent 1y agoRight, small PRs are great. And they are even better with a nice commit history for me to follow. One does not exclude the other.