How compatible is this to git and it's tooling?
Fossil however is mostly incompatible with how Git thinks, since Git is arguably the worst wrapper around an API imaginable, while Fossil is pretty well thought out for smaller dev teams. Fossil will never work for Linux kernel development.
see: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in.
If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
Some of us think actual history is more important than a persons idealized representation of the past.
You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want.
The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free).
And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way.
I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.