4 ms·

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'r

by 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.

by sgbeal 11y ago

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.