4 ms·

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

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.

sgbeal 3y ago
> 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.
- pseudalopex 3y ago
  Subversion had plans to let administrators remove files or commits. Git inspired Mercurial's history editing.
- Buttons840 3y ago
  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.
- danShumway 3y ago
  > 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.
- fanf2 3y ago
  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.

sgbeal 3y ago

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

pseudalopex 3y ago
Subversion had plans to let administrators remove files or commits. Git inspired Mercurial's history editing.
Buttons840 3y ago
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.
danShumway 3y ago
> 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.
fanf2 3y ago
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.