[tangent128]

Squashing changes isn't the only use of rebasing.

It's reasonably common for me to start exploring a problem space, stub out a concept, and have a long drawn-out conversation with the compiler that touches many files, before finally reaching a point that is working enough to be interesting.

At that point, I can take a step back and note that actually, not all of those changes have to be made all at once, and I can break that patch up into a bunch of simpler pieces.

In Git, I have two essentially-equivalent choices:

1. stage the commit in small chunks, adding a separate descriptive comment for each.

2. commit everything as a WIP commit so this working state is in the reflog, then break it up into smaller commits with interactive rebase.

In either process, I'm able to get a better comprehension of my own thoughts along the way.

Fossil, refusing both staging would force me to commit the proverbial 500-line blob all at once, which is less helpful to the reviewer trying to discern my thought process.

If rebasing isn't important to your workflow, Fossil probably is a better choice for you than Git. It has a lot of comforts that I really appreciated even eight years ago when I did frequently use Fossil (distributed wiki and tickets are really nice, the web interface serving raw artifacts from any point in time is great for HTML5 game jams, SQLite is a very portable repository format, etc. etc. etc.), and I'm sure it's only improved in that regard. The only reason I use Git for personal projects is because rebase is that helpful to my process.

[wyoung2]

> Fossil...would force me to commit the proverbial 500-line blob all at once

Nope.

If it were me doing such a thing as you describe, I'd start the work on a feature branch. If I'm working on that repo with other active developers, this lets them see what I'm up to and possibly help; and if not help, then at least be aware about where my head's at, so they can better predict what's likely to land on the shared working branch later.

If I got to a point where only part of the branch needed to be applied, I could cherrypick those individual changes, either down to the parent branch or up to a higher-level feature branch.

All of this happens in public, with the work fully recorded, so someone doesn't have to reconstruct the development history after the fact later.

This mode of development helps keep your project's bus factor above 1.

[tangent128]

You can commit code that doesn't compile onto a feature branch so people can see what you're up to, I guess, but I don't see that helping with bisecting later, and I wouldn't expect the commit messages to be useful.

To be clear, my typical approach is certainly to commit every time I return to a working state. But in more experimental modes, I often reach that the long-way-around and have ended up with multiple semantic changes I wish to break apart for study.

Unless I'm missing something and Fossil has gained the ability to cherry-pick selective lines from a commit.

[kazinator]

Squashing isn't rebasing, period.

The connection between the two is that git has a script called git rebase, which has an interactive mode, and that can squash commits.

git merge has squash functionality also (git merge --squash).