> What is the value in having history be static? [Edited for formatting] Section "3.9 Audit Trail" of "http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w

> What is the value in having history be static? [Edited for formatting] Section "3.9 Audit Trail" of "http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki" http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki" puts it best. It's about being able to audit the history, instead of using history as a kind of documentation of the intent of the changes: Git features the "rebase" command which can be used to change the sequence of check-ins in the repository. Rebase can be used to "clean up" a complex sequence of check-ins to make their intent easier for others to understand. This is important if you view the history of a project as part of the documentation for the project. Fossil takes an opposing view. Fossil views history as sacrosanct and stubbornly refuses to change it. Fossil allows mistakes to be corrected (for example, check-in comments can be revised, and check-ins can be moved onto new branches even after the check-in has occurred) but the correction is an addition to the repository and the original actions are preserved and displayed alongside the corrections, thus preserving an historically accurate audit trail. This is analogous to an accounting practice of marking through an incorrect entry in a ledger and writing a correction beside it. To put it another way, Git remembers what you should have done whereas Fossil remembers what you actually did. The lack of a "rebase" command and the inability to rewrite history is considered a feature of Fossil, not an omission or bug.