Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that? Realistically, squash & rebase is used only to clean up history in those private branches before it gets in the main repo. Fossil doesn't support it on the basis that those local commits are valuable to other developers who work on the code, and I disagree with this as a general claim.
Re:SQLite Doesn't Use Git
by dec0dedab0de on Monday September 12, 2022 @11:14AM
(#32811584)
Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that?
It tends to be developers that are used to the opensource workflow of forking before submitting a patch or pull request. Who are now on a team where everyone's working on branches in the same repo. I understand wanting to combine a bunch of commits that say "trying it like this, trying it like that". but I find it's better to have the noise than lose something important, or cause a messy conflict later on.
I also don't like multiple changes in a single commit. I hate when I look into the commit history of a file and it's "added feature X" which touches 15 different files making changes to multiple code blocks in each. If I want that, I'll look at the merge commits.
I don't have a problem with squashing per se, especially when it's a private branch for a single developer. The problem is when you have multiple developers working on a feature branch together, or when you have to merge in a branch with a fix or feature that has not yet been merged up higher.
My bottom line is I want as few merge conflicts as possible, and I want to see the real author and a relevant commit message if I'm digging into changes to figure out what went wrong with something.