> 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.
auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
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.
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.
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."
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.
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.
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.
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.
We can debate whether Git's default is sensible or not.
Is fossil perfect? Is any software perfect? Of course not. I was merely describing a single pain point I recently experienced that would not have happened without the ability to make changes to published history.
I'm aware there are more options than delete and clone. My options were to spend time trying to fix my clone to which I had made no changes, or I could delete and reclone from the origin. The pragmatic solution was obvious and got me back to work more quickly than I would have otherwise been able to.
The fact that there are more options to allow fixing a broken clone are nice, but irrelevant. Had git not allowed removing published history, it would not have been an issue.
I'm all for the ability to amend history, which fossil does allow (to an extent). What it doesn't support deletion of old history followed by the creation of new history.
> Why do you feel that you _have_ to be able to
> correct history? The past is immutable. Fossil
> treats it as such.
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.
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.
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.