Hacker News Reader

Which is fine for someone to have as a perspective, I just think that philosophy is far too limiting for a universal VC system and misses the point of what many people use VC for.

It's not so much "the people who are designing Fossil are bad at designing it" as much as it is "I disagree with their starting premises and their goals for the thing they're building." If someone comes to me and asks why they would want to use Git over Fossil, the primary thing I would point at is:

> This is how accounting and legal systems work. You never erase - you only add corrections.

I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; I don't think a VC is inherently an accountability system or a legal system, and I think that having that rigidity can get in the way of certain workflows. Again, opinion me, I know you're quite happy with Fossil for SQLite, and that's great and I'm sure it works great. It's not like it's bad to have opinionated tools, I just think that it gets in the way of treating Fossil as something I would recommend as a general Git replacement for everyone.

It comes down to: is the ability to rewrite "history" (which is not even really history at all in Git, it's just a collection of ordered changes) a feature or a problem? Fossil thinks it's a problem, I think it's a feature. Fossil looks at repository history like a historical record, I look at repository "history" as purely an organizational tool for checkpointing/documentation.

> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level;

The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?

Admittedly, rebase/squashing/etc. is _necessary_ for a Linux-kernel-scale project, but 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.

Other version control systems don’t give you tools to manage your work while it is being prepared and reviewed, before it is committed to the shared repository. That is when much of the rewriting happens.

> The Devil's Advocate in me feels compelled to point out that git is the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?

There are a lot of reasons I don't use SVN and CVS, but correct, their branch model is one of them. I do think that Git's restructuring of how commits and branches work and the flexibility around them is one of the reasons its better than older VC systems.

I'm not sure how strict those older VCs actually were, I'm less familiar with them than I am with Git/Fossil, but... yeah I have no problem saying that if they were doing fully immutable history they were wrong to do so (or maybe "wrong" isn't the best term to use, more that it would be an attribute that I think would make them less useful to a lot of developers).

> 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.

I would disagree with this, I think rebasing/squashing is just a really useful tool, even for smaller projects. It's sort of a difficult debate to have because it's mostly going to come down to opinion. What does necessary mean in a smaller project, VC itself is not strictly necessary for many smaller projects.

SQLite gets by fine with Fossil, the developer prefers having an immutable history. But I'm not sure what to say other than that I use rebasing a lot. Different projects have different development styles.

Subversion had plans to let administrators remove files or commits. Git inspired Mercurial's history editing.

Last time I used SVN I rebased all the time, no problem. I was using a git-to-svn bridge though. My point is, people will rewrite history on their own computer whether you want them to or not. Git is the only VCS that doesn't fight against that fact.

> I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography.

Many git users agree, including the kernel from memory. By that I mean there is often some git tree (maybe called "production", "main" or "master") were "fast roll forward" is the only style of commit accepted. Ie, on that tree, you can't change history. But when you're using git to built a commit to that tree, you are allowed (and in the kernel's case expected), to clean the history up, removing all your mistakes and experiments, so the people following the main branch don't have to wade through all that crap.

So the difference is git allows it to be a policy setting, whereas I take it Fossil forces it to be turtles all the way down.

History is only immutable once it's committed to Fossil, and anything not committed is lost forever. This may sound banally obvious, but I think it's fundamentally the problem with Fossil's approach. With git I essentially commit my entire undo/redo stack. I end up discarding most of that later, while with Fossil I would never have committed those intermediate versions in the first place.

Without history rewriting, the rewriting simply takes place before committing instead of after.

Only if you choose to use it like that. I commit every minor detail in Fossil, even little things like "added TODO comment".

I use fossil as my daily driver VCS and I feel like it doesn't go far enough in it's ability to non-destructively amend history. The canonical justification for git-style rewriting is taking all the commits that make up some feature and smashing them down into one "implemented feature X" commit which, as far as I know (?), does not have an analogue in Fossil. Even something like forgetting to add a file to a commit requires an additional commit (and shows up as such on the timeline) with a silly "forgot to include file foo in commit whatever" comment.

Ideally there'd be some kind of "virtual commit" capable of (visually) bundling up a range of commits, with its own message and tags; maybe these could be nested so that you could have a hierarchical view of the timeline: initially you see "release X, release Y" but then you can expand any of those to "implemented feature A, B" which can be further expanded into the actual commits.