this post was submitted on 04 Apr 2024
1113 points (98.2% liked)
Programmer Humor
19623 readers
1 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No. You should never squash as a rule unless your entire team can't be bothered to use git correctly and in that case it's a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.
Rebase "merges" are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn't. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
I don't want to see a dozen commits of "ran isort" "forgot to commit this file lol" quality.
Do you?
Having the finished feature bundled into one commit is nice. I wouldn't call it stupid at all.
Note that I didn't say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.