With regard to rebase and fossil vs git when you have a small team of trusted developers rebase is harmful because you lose information that could help you understand the _why_ of something. In contrast if you are working with thousands of untrusted developers you need a way to increase the signal-to-noise at the cost of some granularity.
I don’t understand the dislike of rebase — do you want hundreds of commits that say “linter fix” and “reformatting”?
If there’s commits like “fixed off by one issue in refactor” then it should be a comment in the code so that future will explorers won’t make the same mistake.
Rebase by itself isn’t bad, it just has to contain a good description of what was done and why.
Edit: after posting I realize that I confounded rebase and squash — which is kind of ingrained in my head as that’s how I use GitHub to merge PRs.
They are better than one single commit with 100s of changed files. Especially when you are debugging things and want to know why exactly some line was changed in that way and by whom.
This comes about from their development styles (see: http://www.catb.org/~esr/writings/cathedral-bazaar/).
- Use fossil if you prefer the cathedral style of development SQLite is open source but does not accept contributions.
- Use Git if you prefer the bazaar style of development. You want to accept hit-and-run style contributions from anyone.