4 ms·

> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically

> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collaboration that also allows me to have documentation around repository history, and I don't think that immutable history helps with either documentation or collaboration. Obviously some people disagree with me on that, but the really short answer is that I think the way Fossil defines version control is misguided, so it's unlikely I would ever make the switch over.

SQLite 3y ago
Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. 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. Mistakes happen, and it is important to be able to correct them, which Fossil does do. In many ways Fossil's mistake-correction logic is far better than Git's. If you make a check-in to the wrong branch, you can move it after the fact in Fossil. If you check-in with the wrong user-id, or a with a goofy check-in comment, you can edit those too. Was your system clock wonky when you did the commit, resulting in a bad timestamp on the check-in, that too can be fixed. I say "edit" - really you are not modifying the original check-in at all. The original check-in is immutable. But Fossil supports the ability to add correction records (tags) on top of check-ins. The original history is preserved and you can always drill down to find out exactly what happened. But for routine day-to-day usage, only the corrected values are shown on displays and reports. So it is like being able to change history, except that you are left with an audit trail. This is how accounting and legal systems work. You never erase - you only add corrections.
- danShumway 3y ago
  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.
- plorkyeran 3y ago
  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.
  - professoretc 3y ago
    Only if you choose to use it like that. I commit every minor detail in Fossil, even little things like "added TODO comment".
- professoretc 3y ago
  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.
- rstuart4133 3y ago
  > 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.
Buttons840 3y ago
Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers. If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil. Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people. [0]: https://github.com/martinvonz/jj https://github.com/martinvonz/jj
- funklute 3y ago
  > then git gives you the tools to ensure the repos you control are not rewritten I might betray my ignorance here, but what tools are those? If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?
  - Buttons840 3y ago
    > I can obviously ensure that any branches on the origin are never rewritten That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it. We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history? Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present. (I've rambled on here, most of this isn't meant as a direct reply to you.)

SQLite 3y ago

Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. 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. Mistakes happen, and it is important to be able to correct them, which Fossil does do. In many ways Fossil's mistake-correction logic is far better than Git's. If you make a check-in to the wrong branch, you can move it after the fact in Fossil. If you check-in with the wrong user-id, or a with a goofy check-in comment, you can edit those too. Was your system clock wonky when you did the commit, resulting in a bad timestamp on the check-in, that too can be fixed. I say "edit" - really you are not modifying the original check-in at all. The original check-in is immutable. But Fossil supports the ability to add correction records (tags) on top of check-ins. The original history is preserved and you can always drill down to find out exactly what happened. But for routine day-to-day usage, only the corrected values are shown on displays and reports. So it is like being able to change history, except that you are left with an audit trail. This is how accounting and legal systems work. You never erase - you only add corrections.

danShumway 3y ago
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.
plorkyeran 3y ago
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.
- professoretc 3y ago
  Only if you choose to use it like that. I commit every minor detail in Fossil, even little things like "added TODO comment".
professoretc 3y ago
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.
rstuart4133 3y ago
> 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.

Buttons840 3y ago

Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers. If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil. Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people. [0]: https://github.com/martinvonz/jj https://github.com/martinvonz/jj

funklute 3y ago
> then git gives you the tools to ensure the repos you control are not rewritten I might betray my ignorance here, but what tools are those? If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?
- Buttons840 3y ago
  > I can obviously ensure that any branches on the origin are never rewritten That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it. We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history? Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present. (I've rambled on here, most of this isn't meant as a direct reply to you.)