It so happen that I usually do commit squashed changes to many files over code base with long and heavy legacy. I am afraid that squashed changes lose their utility for bisection search for a bug.
You could also just filter down to merge commits when you look at history. I think if gitlab and github supported this, many people would change their minds about squashing or rebasing.
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.
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.
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.
How do squash commits maintain bisectability? They do compress history, and granularity is lost, so one can bisect, but on large batches of code (to be specific, as large as merges; if a team adopts small merges, the granularity is retained, but the amount of branches may be untenable). One can keep the private (pre-squash) branches, but they won't be in the main branch history, so one can't bisect.
The sad reality is that testing and reviewing will only get us to defect density of one defect per 1000 lines of code changed - a nice round number for a clarity of discussion (and we are lucky here, see below). E.g., if patch changes or adds 300 lines of code, which is not unusual amount of code, the probability of defect is 1/3. My changeset right now contains 320 files and 3200 lines added or changed (a fix for long standing defect in design). It is not green in testing, but you get the idea: it is quite probably I will introduce some defect into main branch. Three against one that I will and it'll pass review.
Usually, private branches are get deleted after merge happen.
In the end, I will have a situation where there is a defect in the main branch and there is no way to bisect it narrower than to squashed commit.
What should I do with 3200 changed lines in 320 files when there is a defect?
The page above hints that pre-review defect density for C/C++ code is 4.5 defects per 100 lines of code. After review it is 0.82 defects per 100 LOC, or 8.2 defects per 1000 lines of code. My big patch will introduce 25 defects that'll pass review. Even 10 fold decrease in defect density after testing (haha) will not significantly reduce probability of the introduction of a single defect.
Either you can break your big commit down into pieces that can be applied one by one - then do that using history rewriting (and testing each part!).
Or that's not possible, e.g. because it's a global architecture change or something that is already atomar. Then there is nothing to bisect anyway - there is nothing that can be done, no matter which tool you use and no matter if you squash or not.
When commit is squashed and rebased upon main branch there is no pieces to bisect.
Having private branches also does not always work. For example, there was a purge of unnecessary branches in our main repository. If I use a fork of main repository (and I do), my private branches are also not readily available to the team.
I've seen that, and even successfully fought against it once. I've also been on teams that don't treat it as a religious issue in the first place, and people rebase or merge from their private forks as they see fit.
Personally, I think that the only bar that is necessary is that commit history should remain readable - which is subjective, but that's why we have code reviews. In any case, this is not an issue with the tool, but rather with the religion that formed around it, which is often the case with software tooling.
One thing that helps a lot with a pragmatic consensus is to ensure that all members of the team have personal experience debugging old code that they didn't write or previously review.
It so happen that I usually do commit squashed changes to many files over code base with long and heavy legacy. I am afraid that squashed changes lose their utility for bisection search for a bug.
Yet, I required to do so. Mainly, because I can.