12 ms·

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action lea

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the internal data model to be quite complicated, but certainly not impossible. I don't understand the hate against rebase. Nobody uses it with malicious intent. And, those who do, will have no problem working around fossil's immutability.

jimktrains2 11y ago
> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm working locally, commit an absurd number of commits in stream-of-programming style, and then go back and clean it up before pushing to the shared repo. What is the analogous workflow in fossil?
- sgbeal 11y ago
  > What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
  - avar 11y ago
    That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you. What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew. Nobody needs audibility on unfinished work that hasn't been pushed to the central repositories (and would thus be protected by non-fast-forward). To the extent that you would fossil doesn't make the situation better, if I can't fix up my commits after the fact before I push them I'm just not going to make those intermediate commits in the first place, which gives the system no more information to work with, and results in a less convenient workflow for me. This whole "we preserve history forever" statement is a red herring. They've just picked a data model which is hard-immutable, but it doesn't mean that they're categorically preserving more information, or that tools that have configurable-immutable datamodels (like Git) preserve less history in practice.
    - sgbeal 11y ago
      Why do you feel that you _have_ to be able to correct history? The past is immutable. Fossil treats it as such. git does not, no matter what configuration you're running - i can always create a fork, modify the history in my fork, and publish that. git has mutable history, period. fossil does not, period. They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes.
      - jimktrains2 11y ago
        > Why do you feel that you _have_ to be able to correct history? Why do you feel I shouldn't be able to do what I want with my history before others see it? Shared repos can reject history rewrites, as the parent said. Also, as others have said, fossil does not provide the tools to mutate history, but that doesn't mean that history is immutable. > They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes. Who's talking about mistakes? I'm talking about cleaning up a stream of small commits I've made over the day into a smaller number of coherent, sensible commits.
        sgbeal 11y ago
        "Mistakes" was indeed a poor choice of words, but the principle is the same: fossil does not allow the public record (mistake or otherwise) to change, with the one exception of the "nuclear option" (shunning, which forcibly removes content from the repo). git allows the public record to be flexible forever. "History is written by the victors." Fossil believes that everything in the repo is in the public record and that the public record must never change. "History is recorded as it happened."
        jimktrains2 11y ago
        > fossil does not allow the public record (mistake or otherwise) to change, But you can do the same in git -- the shared repo can reject non fast-forwards. This allows you to rebase your _private_ history and enforces consistency off the share. Granted, in a peer-to-peer model this is less useful, but that isn't how most teams work nor is it how a team that needs immutable history would work.
  - adwn 11y ago
    > Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability. I work for a company that builds machines to be sent into space (specifically, electronics and high-tech instruments), and I have never heard of such a requirement. The end result matters to our customers, not the thousands of commits in our Subversion repository.
    - sgbeal 11y ago
      i don't know which business you work for, but i have it on good authority (from an unspecified sqlite core developer) that getting software into commercial airplanes requires 100% auditability of the source history. i _assume_ that's the same for space travel - maybe not, or maybe it depends on the context.
- dcuthbertson 11y ago
  > 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.
- Fice 11y ago
  > What is the analogous workflow in fossil? Private branches: https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki
- wyoung2 11y ago
  > What is the value in having history be static? Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard. > I find that rebase comes in handy as I'm working locally This idea that local development is a good thing is one of the biggest differences between Git and Fossil. Git was created to serve the needs of the Linux kernel, where the development effort is not only distributed, but also federated, with islands of development sporadically pushing changes higher up the tree. You see this on Github, with semi-private forks of projects containing changes that never make their way back into the primary project. If that is the sort of project you're working on, Git is the right tool. Fossil, however, is meant for much more cohesive teams. While it does allow one to go off on a tangent, developing for weeks at a time with no outsiders ever seeing what you're doing, that is not its default mode. In Fossil's default mode, local checkins are immediately sync'd back to the repo you cloned from, which is typically the official central repo. Fossil allows you to have chains of repos (A clones from B, which cloned from C, which cloned from D...) but a simple 2-level fan-out is much more common. I think of Fossil as a DVCS with the day-to-day workflow sensibility of Subversion. The DVCS aspect means you can take your laptop to the mountains with you, code for a week in your tent while your relatives all enjoy the dubious pleasures of nature (the weirdos) then come back home and sync back up with the central repo, your whole change history being grafted back in as if you'd been autosyncing to it the whole time. The Subversion sensibility means that while working in the office, every checkin normally becomes immediately visible to your team members, as do theirs to you. While this makes some people nervous — particularly those who have only used Git — it has benefits. I can state those benefits in terms of the [Ten Commandments of Egoless Programming](http://goo.gl/13r3xT http://goo.gl/13r3xT), published by Gerald Weinberg way back in 1971 as [The Psychology of Computer Programming](http://goo.gl/NqqGnl http://goo.gl/NqqGnl). Using his numbering: 1. You will make mistakes, but Git encourages you to hide them in the stash, in private branches, in changed checkin comments (git commit --amend), and in history rewrites. In its default working mode, Fossil pushes every checkin immediately back to the repo you cloned from, where they can be noticed and fixed ASAP. The longer an error goes unnoticed, the greater the damage it can do. 2. You are not your code. Private branches are a symptom of the sort of perfectionism that violates this commandment. You don't want to spend a week going off on a tangent when one of your colleagues could have saved you from wasting your time by seeing the path you started down with your first commit. Fossil has a way to create private branches, but unlike Git, it isn't the default mode. Defaults matter. 4. Don't rewrite other people's code without consultation. You've worked with that guy. You know, the one who runs the whole codebase through indent(1), the one who changes multi_word_function_names to camelCase, the one who "refactors" things endlessly. Git's default mode of working on a private branch, then pushing a bunch of work as a single bolus makes this sort of fiddling worse. Fossil's default autosync mode lets you detect that sort of thing early and nip it in the bud. 6. The only constant in the world is change. So, when a colleague makes a change in trunk that breaks your change-in-development, you want to pull it into your tree ASAP so you can fix up the problem before trying to merge your change in. You don't want to find out a week later when you and your colleague both try to check in week-old private branches, and find that you'll need another day or two of work to fix up the differences. 9. Don't be "the guy in the room." But Git wants you to be that guy. Before you can check a change in with Fossil, it first checks if there are any changes in the repo you cloned from, and makes you either say "fossil up" to pull them into your local repo, or check in on a branch. This encourages you to either test your changes against the tip of trunk before checkin in, or at least publish your changes as a branch so people can see you go haring off in a different direction, and maybe correct your trajectory. Not all merge conflicts can be detected by the VCS's merge algorithm. Just because your changes merge cleanly into the central code repo doesn't mean you haven't broken the build, or the tests, or... Fossil encourages you to test your change against the tip of the branch you're working on before checking in. Git amounts to a social regression with respect to Egoless Programming.
sgbeal 11y ago
> Ehm, That's not a fair assessment. Git is as much immutable as fossil. HA! HAHA! HAHAHA!!!! For any reasonable definition of "immutable," git is most certainly NOT immutable.
- jimktrains2 11y ago
  A tree with a known hash will never change.

jimktrains2 11y ago

> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm working locally, commit an absurd number of commits in stream-of-programming style, and then go back and clean it up before pushing to the shared repo. What is the analogous workflow in fossil?

sgbeal 11y ago
> What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
- avar 11y ago
  That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you. What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew. Nobody needs audibility on unfinished work that hasn't been pushed to the central repositories (and would thus be protected by non-fast-forward). To the extent that you would fossil doesn't make the situation better, if I can't fix up my commits after the fact before I push them I'm just not going to make those intermediate commits in the first place, which gives the system no more information to work with, and results in a less convenient workflow for me. This whole "we preserve history forever" statement is a red herring. They've just picked a data model which is hard-immutable, but it doesn't mean that they're categorically preserving more information, or that tools that have configurable-immutable datamodels (like Git) preserve less history in practice.
  - sgbeal 11y ago
    Why do you feel that you _have_ to be able to correct history? The past is immutable. Fossil treats it as such. git does not, no matter what configuration you're running - i can always create a fork, modify the history in my fork, and publish that. git has mutable history, period. fossil does not, period. They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes.
    - jimktrains2 11y ago
      > Why do you feel that you _have_ to be able to correct history? Why do you feel I shouldn't be able to do what I want with my history before others see it? Shared repos can reject history rewrites, as the parent said. Also, as others have said, fossil does not provide the tools to mutate history, but that doesn't mean that history is immutable. > They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes. Who's talking about mistakes? I'm talking about cleaning up a stream of small commits I've made over the day into a smaller number of coherent, sensible commits.
      - sgbeal 11y ago
        "Mistakes" was indeed a poor choice of words, but the principle is the same: fossil does not allow the public record (mistake or otherwise) to change, with the one exception of the "nuclear option" (shunning, which forcibly removes content from the repo). git allows the public record to be flexible forever. "History is written by the victors." Fossil believes that everything in the repo is in the public record and that the public record must never change. "History is recorded as it happened."
        jimktrains2 11y ago
        > fossil does not allow the public record (mistake or otherwise) to change, But you can do the same in git -- the shared repo can reject non fast-forwards. This allows you to rebase your _private_ history and enforces consistency off the share. Granted, in a peer-to-peer model this is less useful, but that isn't how most teams work nor is it how a team that needs immutable history would work.
- adwn 11y ago
  > Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability. I work for a company that builds machines to be sent into space (specifically, electronics and high-tech instruments), and I have never heard of such a requirement. The end result matters to our customers, not the thousands of commits in our Subversion repository.
  - sgbeal 11y ago
    i don't know which business you work for, but i have it on good authority (from an unspecified sqlite core developer) that getting software into commercial airplanes requires 100% auditability of the source history. i _assume_ that's the same for space travel - maybe not, or maybe it depends on the context.
dcuthbertson 11y ago
> 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.
Fice 11y ago
> What is the analogous workflow in fossil? Private branches: https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki
wyoung2 11y ago
> What is the value in having history be static? Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard. > I find that rebase comes in handy as I'm working locally This idea that local development is a good thing is one of the biggest differences between Git and Fossil. Git was created to serve the needs of the Linux kernel, where the development effort is not only distributed, but also federated, with islands of development sporadically pushing changes higher up the tree. You see this on Github, with semi-private forks of projects containing changes that never make their way back into the primary project. If that is the sort of project you're working on, Git is the right tool. Fossil, however, is meant for much more cohesive teams. While it does allow one to go off on a tangent, developing for weeks at a time with no outsiders ever seeing what you're doing, that is not its default mode. In Fossil's default mode, local checkins are immediately sync'd back to the repo you cloned from, which is typically the official central repo. Fossil allows you to have chains of repos (A clones from B, which cloned from C, which cloned from D...) but a simple 2-level fan-out is much more common. I think of Fossil as a DVCS with the day-to-day workflow sensibility of Subversion. The DVCS aspect means you can take your laptop to the mountains with you, code for a week in your tent while your relatives all enjoy the dubious pleasures of nature (the weirdos) then come back home and sync back up with the central repo, your whole change history being grafted back in as if you'd been autosyncing to it the whole time. The Subversion sensibility means that while working in the office, every checkin normally becomes immediately visible to your team members, as do theirs to you. While this makes some people nervous — particularly those who have only used Git — it has benefits. I can state those benefits in terms of the [Ten Commandments of Egoless Programming](http://goo.gl/13r3xT http://goo.gl/13r3xT), published by Gerald Weinberg way back in 1971 as [The Psychology of Computer Programming](http://goo.gl/NqqGnl http://goo.gl/NqqGnl). Using his numbering: 1. You will make mistakes, but Git encourages you to hide them in the stash, in private branches, in changed checkin comments (git commit --amend), and in history rewrites. In its default working mode, Fossil pushes every checkin immediately back to the repo you cloned from, where they can be noticed and fixed ASAP. The longer an error goes unnoticed, the greater the damage it can do. 2. You are not your code. Private branches are a symptom of the sort of perfectionism that violates this commandment. You don't want to spend a week going off on a tangent when one of your colleagues could have saved you from wasting your time by seeing the path you started down with your first commit. Fossil has a way to create private branches, but unlike Git, it isn't the default mode. Defaults matter. 4. Don't rewrite other people's code without consultation. You've worked with that guy. You know, the one who runs the whole codebase through indent(1), the one who changes multi_word_function_names to camelCase, the one who "refactors" things endlessly. Git's default mode of working on a private branch, then pushing a bunch of work as a single bolus makes this sort of fiddling worse. Fossil's default autosync mode lets you detect that sort of thing early and nip it in the bud. 6. The only constant in the world is change. So, when a colleague makes a change in trunk that breaks your change-in-development, you want to pull it into your tree ASAP so you can fix up the problem before trying to merge your change in. You don't want to find out a week later when you and your colleague both try to check in week-old private branches, and find that you'll need another day or two of work to fix up the differences. 9. Don't be "the guy in the room." But Git wants you to be that guy. Before you can check a change in with Fossil, it first checks if there are any changes in the repo you cloned from, and makes you either say "fossil up" to pull them into your local repo, or check in on a branch. This encourages you to either test your changes against the tip of trunk before checkin in, or at least publish your changes as a branch so people can see you go haring off in a different direction, and maybe correct your trajectory. Not all merge conflicts can be detected by the VCS's merge algorithm. Just because your changes merge cleanly into the central code repo doesn't mean you haven't broken the build, or the tests, or... Fossil encourages you to test your change against the tip of the branch you're working on before checking in. Git amounts to a social regression with respect to Egoless Programming.

sgbeal 11y ago

> Ehm, That's not a fair assessment. Git is as much immutable as fossil. HA! HAHA! HAHAHA!!!! For any reasonable definition of "immutable," git is most certainly NOT immutable.

jimktrains2 11y ago
A tree with a known hash will never change.