Only with a fair amount of pain (basically, `fossil merge --cherrypick`, then `fossil purge` for the original branch). That's because mutable history is not pa

Only with a fair amount of pain (basically, `fossil merge --cherrypick`, then `fossil purge` for the original branch). That's because mutable history is not part of the normal workflow that's being encouraged by fossil. You will see that "wrong" branches are simply tagged as "mistake" in the Fossil or SQLite repositories [1]. Branches are merged rather than rebased and the web UI is built around the assumption of having branches as distinct, named entities, rather than having them coalesced into the mainline. Fossil also uses autosync by default, where commits are automatically pushed to the master repository, which further discourages changing history. If you simply want a local checkpointing mechanism (where you snapshot revisions at intervals with the intent to later combine them into a single meaningful commit), that's what private branches or `fossil stash snapshot` are for. Commit metadata, such as commit messages, can be changed later, but the edits leave an audit trail. A major reason here is specifically that changes are supposed to always have an audit trail. [1] https://www.sqlite.org/cgi/src/timeline?n=100&r=mistake https://www.sqlite.org/cgi/src/timeline?n=100&r=mistake