I despise squashs. It encourages people to tread git commit as a glorified ^S of their work.
You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of "hmmmm" "why no work?" "try something" etc commits.
> I despise squashs. It encourages people to tread git commit as a glorified ^S of their work.
I can’t imagine working with git any other way. Do you hold off committing because you haven’t collected your thoughts enough to craft a good message? What if your editor crashes and you lose your undo history? How do you get back to the last state where the code compiled? If some plan of attack doesn’t work, you just… reset hard and lose it forever?
I can’t count the number of times I’ve done something like the following:
- Try approach A
- Approach A sucks, commit what I’ve done so far, try approach B
- B sucks too, commit again and switch back to A (oh hey, there it is in my reflog!)
- Turns out I need a combination of A and B. Oh hey, a simple git diff shows me the deltas. Awesome!
- Repeat
- Once I’m ready to make the PR, I squash it all, craft a thoughtful, meaningful commit message, look at the commit as if I’m a reviewer, verify it all makes sense in context as a single commit.
(oh and by the end, the commit may be a SINGLE CHARACTER! Precisely what the author of this article is talking about! Is it your contention that every dead-end the author hit should have a permanent place in the repo’s commit history, forever?)
In your world, do you just… not use git at all here? Do you never try approach until you’re sure it’s the right one? You only commit when you have something you want someone else to see? That’s nuts to me. You’re absolutely missing out on some of the best workflow git has to offer.
Squashes and rebaseses, used properly, are done prior to committing work into a shared major branch (like trunk or develop or whatever). The goal of the squash is to make the resulting commit atomic.
This is a false dichotomy. Someone creating the "fix problem" commits is not going to suddenly write great commit messages because the merge strategy changed.
The root evil is actually MRs that live longer than a day or two, and change too much code at once.
Sometimes units of work that a branch would reflect are larger. I agree there are some branches that grow larger than they should, but often there are branches that involve a good number of changes, and breaking it into smaller branches doesn't really make sense either. There will always be branches where there should be multiple meaningful commits, and automatically squashing them all together just defeats the purpose of good commit messages. I don't buy into the idea that branches should always have just one commit or be reflected as a single commit on merge.
Most of my commits are indeed a glorified ^s. Doing this does require some discipline though. You’ve got to pay attention to when you’ve reached a point that the accumulated changes represent a reasonably small, but complete unit of work that should be squashed and documented with a good commit message.
You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of "hmmmm" "why no work?" "try something" etc commits.