Fossil doesn't do rewriting history. I think that rules it out for large team efforts. As an immutable distributed log of everything I write by myself it's essentially perfect.
Can you fake it by constructing a new branch with the history you want, copying files between branches from appropriate commits?
Easier is to copy the repo, do a bunch of feature work there, then rsync over to the shared repo and commit. I don't bother though, local history has the mistakes and backtracking enshrined.
What I like about this question, however, is what it reveals about our assumptions, and what it says about what the words “commit” and “history” mean, and what it is we want out of a version control system.
The truth is that a commit is what I say it is, whether I’m using git or Fossil or anything else. This means that it’s absolutely always guaranteed to be subjective, and has only the meaning I give it. Preventing rewrites might have some workflow benefits, I’m quite open to the idea that there are advantages to the way Fossil does things. But the idea that rewrites should be prevented in principle because history should be preserved is really very funny to me. It’s only possible to preserve the history of the things I said are history in the first place.
"Purge" is really only intended for use with fossil's "bundle" feature, bundles being essentially feature-rich patches which record all of the historical state of the bundle. (Yes, it's long been flagged as experimental, but it's also been unchanged since it was added so i'll look into getting that notice removed or amended.)
The idea of fossil's bundles is that a person not associated with a project can submit a patch in the form of a bundle, a developer imports that bundle into their repo and either retains it or "purges" it, leaving the developer's repo clone back in a clean pre-bundle state. That feature can, however, and sometimes is, used for "popping" the top-most commit from a repository (so long as it has not yet been pushed to a remote). So long as a local repo has not been synced with any remotes, and so long as there are no branch points to interfere with it, repeated applications the bundle/purge combo can be used to pop the top-most checkin multiple times, effectively wiping out as-yet-unsynced changes even if they span multiple checkins.
Git rebase provides a new, second, altered sequence of commits. It doesn’t replace the original. We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history.
Git never promised a “history” per se, not in the form of an immutable record of events. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too.
Good point. Perhaps "rewrite history" is not the best metaphor, and does not cover all possible git workflows. I only considered the workflows where a rebased branch is merged back onto master instead of its non-rebased variant, which loses its name, its remote copy/copies and is eventually hit by the GC.
> the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git.
The resistance I've met among developers to adopt rebasing workflows with git have no knowledge of Fossil.
My impression is that the main objection to such workflows is that it exceeds some developers' novelty budget [0] and that those developers generally don't read git messages and don't value the history of code to understand its current shape.
FWIW, my intro to rebase came after using Perforce for years. Because git is strict about commit ordering and P4 is not, I was struggling to figure out how to manage multiple in-flight changes like I would in P4, and how to clean up and push something that wasn't a hot mess. Rebasing my local workspace, it turned out, is the answer to that. It is the key to working around git's strict commit parentage, and makes it easy to sculpt changes so they're palatable for me and my team.
Above I was referring to some of the anti-rebase messaging Fossil has put out in the past. Some is there still, for example https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I'm quite pleased to see that a lot of the most hyperbolic verbiage is gone now, it used to carry on quite a bit. But that page still says rebase is "dishonest", which is a deeply ironic claim, if you catch my drift. That kind of mis-representation ruffles my feathers a little bit, but I've had discussions with the Fossil team right here on HN about it, and they have in fact been open to listening, responsive, and willing to change and improve the messaging.
Fossil heavily discourages (outright forbids?) this kind of stuff.
I would argue the team-wide destination branch history is what should be called “history”, and the only thing that matters. But Fossil’s distinction is more rigid and it considers anything ever committed to be history.
Squashing a local branch does, in a way, rewrite local commit history. But this shouldn’t be called “rewriting history” in my book. Rebasing the main branch really is fully rewriting history (and this isn’t a squash commit). Squashing a feature branch that multiple people touch is somewhere in between. It’s a little rewriting. It’s often desirable. Should squashing small feature branch PRs be called “rewriting history” in the sense that Fossil claims that it’s intended to misrepresent the project? I don’t really think so, but since “rewriting history” wasn’t clearly defined, it’s open for debate.
That’s horrible, sounds like a blockchain oO !
In my workflow I constantly create throw away commits. Once I am satisfied with the code changes I cleanup history and open a PR.
Both bitcoin and git use merkle trees to prevent (unwanted) history rewrites :)