4 ms·

> 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

by 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.
  - data_hope 11y ago
    uh, this is a very pessimistic view on history rewriting. Much more common probably is the fact that one tries to persist very gradually local changes, and once the dust has settled, submit a much coarser commit. Because most of the time all these "fixup this", "add missing imports" commits are really of nobodies interest any more. If you hold on to a git hash, you are can identify history changes very easily.
  - wereHamster 11y ago
    > Why do you feel that you _have_ to be able to correct history? We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history. The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux kernel), with a dozen or more small commits which the developer did while working on that feature, each of which most likely has just some nonsense text as the commit message. If you really see the value of preserving every single individual step which the developer has taken, you should record every keystroke, so that you capture every mistake and typo and all the intermediary states of the source code. Or go even further and record every conversation, meeting and all the coffee breaks chats which may or may not be relevant to the feature the developers are just now working on.
    - CasaDeRobison 11y ago
      Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I never make changes to it. Yet after pulling updates, my repo was in a state claiming I had changes to commit. The whole problem was someone who did rewrite published history. In my case the 'fix' was easy. Delete my clone and reclone. If it had been a project I needed to commit to as well, I doubt fixing the problem would have been nearly as straightforward. Sure, "rewriting history" with fossil could be done by anyone with sufficient skill and patience. The lack of such functionality as "first class features" of the software mean that it is unlikely to happen.
      - wereHamster 11y ago
        You lay the burden to ensure that you can't make mistakes (rewrite history) on the developers of fossil. If, for some reason, fossil allowed to rewrite the history it would be considered a bug and promptly fixed. Yet, for some reason, you don't expect the same from the sysadmins who set up the git repository (ie. set it up so that non-fast forward updates are rejected). We can debate whether Git's default is sensible or not.
  - avar 11y ago
    I'll reply to both this and your downstream comment here for simplicity. > Why do you feel that you _have_ to be able to > correct history? The past is immutable. Fossil > treats it as such. Opinions differ on what aspect of the past should be made immutable. Should we be recording every single one of your keystrokes in a commit? How about just every time you hit "save" in your editor? Git takes the view that making commits is just like hitting "save" in your editor, it's not inherently an operation you want to publish as-is. You can just as well do this with fossil, whatever the tool's guarantees of immutability I can always just cp an older version of the directory to get around it and re-do my commits, which on some level is exactly what "git rebase" is doing. Git just makes this process that people have a good reason to do more convenient. Just like I don't want to see every single one of your keystrokes or every one of your "save" snapshots when reviewing your code I have no reason to be reading hundreds of your "oops, compilation error" commits. Of course I suspect that you don't get much of that with Fossil in the first place, because due to this idealism of immutable history people just aren't using the SCM except for "real" work. Which I think sucks, Git has saved me multiple times with some bug I've introduced mid-editing session because I could bisect my 100 "another snapshot" commits, commits that I then subsequently rebased into 1-5 commits and pushed upstream. > Git allows the public record to be flexible forever. This is just not at all the case in practice. With Git the difficulty of rewriting history increases as a function of how widely that history is published. Fossil proponents seem to think that established history is being regularly willy-nilly written by projects that use Git. The mainline history of git.git, or linux-2.6.git etc. is not being rewritten and never will. What is being rewritten is locally authored commits that haven't been pushed yet, or topic branches that get deleted and replaced by other versions (e.g. with typos fixed in commit messages etc.). You can use Git like Fossil, but most people just choose not to because it doesn't make sense.
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.

by 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.
- data_hope 11y ago
  uh, this is a very pessimistic view on history rewriting. Much more common probably is the fact that one tries to persist very gradually local changes, and once the dust has settled, submit a much coarser commit. Because most of the time all these "fixup this", "add missing imports" commits are really of nobodies interest any more. If you hold on to a git hash, you are can identify history changes very easily.
- wereHamster 11y ago
  > Why do you feel that you _have_ to be able to correct history? We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history. The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux kernel), with a dozen or more small commits which the developer did while working on that feature, each of which most likely has just some nonsense text as the commit message. If you really see the value of preserving every single individual step which the developer has taken, you should record every keystroke, so that you capture every mistake and typo and all the intermediary states of the source code. Or go even further and record every conversation, meeting and all the coffee breaks chats which may or may not be relevant to the feature the developers are just now working on.
  - CasaDeRobison 11y ago
    Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I never make changes to it. Yet after pulling updates, my repo was in a state claiming I had changes to commit. The whole problem was someone who did rewrite published history. In my case the 'fix' was easy. Delete my clone and reclone. If it had been a project I needed to commit to as well, I doubt fixing the problem would have been nearly as straightforward. Sure, "rewriting history" with fossil could be done by anyone with sufficient skill and patience. The lack of such functionality as "first class features" of the software mean that it is unlikely to happen.
    - wereHamster 11y ago
      You lay the burden to ensure that you can't make mistakes (rewrite history) on the developers of fossil. If, for some reason, fossil allowed to rewrite the history it would be considered a bug and promptly fixed. Yet, for some reason, you don't expect the same from the sysadmins who set up the git repository (ie. set it up so that non-fast forward updates are rejected). We can debate whether Git's default is sensible or not.
- avar 11y ago
  I'll reply to both this and your downstream comment here for simplicity. > Why do you feel that you _have_ to be able to > correct history? The past is immutable. Fossil > treats it as such. Opinions differ on what aspect of the past should be made immutable. Should we be recording every single one of your keystrokes in a commit? How about just every time you hit "save" in your editor? Git takes the view that making commits is just like hitting "save" in your editor, it's not inherently an operation you want to publish as-is. You can just as well do this with fossil, whatever the tool's guarantees of immutability I can always just cp an older version of the directory to get around it and re-do my commits, which on some level is exactly what "git rebase" is doing. Git just makes this process that people have a good reason to do more convenient. Just like I don't want to see every single one of your keystrokes or every one of your "save" snapshots when reviewing your code I have no reason to be reading hundreds of your "oops, compilation error" commits. Of course I suspect that you don't get much of that with Fossil in the first place, because due to this idealism of immutable history people just aren't using the SCM except for "real" work. Which I think sucks, Git has saved me multiple times with some bug I've introduced mid-editing session because I could bisect my 100 "another snapshot" commits, commits that I then subsequently rebased into 1-5 commits and pushed upstream. > Git allows the public record to be flexible forever. This is just not at all the case in practice. With Git the difficulty of rewriting history increases as a function of how widely that history is published. Fossil proponents seem to think that established history is being regularly willy-nilly written by projects that use Git. The mainline history of git.git, or linux-2.6.git etc. is not being rewritten and never will. What is being rewritten is locally authored commits that haven't been pushed yet, or topic branches that get deleted and replaced by other versions (e.g. with typos fixed in commit messages etc.). You can use Git like Fossil, but most people just choose not to because it doesn't make sense.

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.