12 ms·

Is rebasing possible in fossil? I was led to believe it was difficult since the commit history was immutable.

jimktrains2 9y ago
Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at. It is nice that additional things besides source can be tracked, bug requests for instance.
- rbehrends 9y ago
  > Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. This is probably in reference to this old message by Richard D. Hipp [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C
- oblio 9y ago
  svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
  - jimktrains2 9y ago
    It also comes from how git is used. With git small commits are possible. It's nice to be able to manage those and build larger, coherent ones. Also, because of the distributed nature, sometimes rewriting is useful to fix mistakes. However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.
rbehrends 9y ago
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

Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at. It is nice that additional things besides source can be tracked, bug requests for instance.

rbehrends 9y ago
> Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. This is probably in reference to this old message by Richard D. Hipp [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C
oblio 9y ago
svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
- jimktrains2 9y ago
  It also comes from how git is used. With git small commits are possible. It's nice to be able to manage those and build larger, coherent ones. Also, because of the distributed nature, sometimes rewriting is useful to fix mistakes. However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.

rbehrends 9y ago

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