4 ms·

Articles like this are eye opening to me, in a bad way. Every once in a while, I get really curious about giving Fossil a try, because it does have some legitim

Articles like this are eye opening to me, in a bad way. Every once in a while, I get really curious about giving Fossil a try, because it does have some legitimately cool ideas, and then I see the documentation saying things like: > Rebasing is the same as lying And I think, "Holy crud do I not want to be part of this community." The nice thing about Git is that (within reason) once I understood it, I was able to use it in very flexible ways. It's really common for different projects I manage to range all over the place from the extreme "commits as literal history" perspective all the way to the "commits as literature/guide" perspective. Sometimes I don't rebase at all, sometimes I rebase a lot. Sometimes I commit everything, all the time, sometimes I refuse to commit any code that isn't a deployable feature. Sometimes I leave branches as historical artifacts, sometimes I don't care about history and I'm just trying to coordinate developers across timelines. That's not to say that Git isn't opinionated about some things -- nearly all good tools have at least a few strong opinions. But Git passes the (IMO extremely low) bar of not conflating a workflow decision with a moral failing. Over the years as a software engineer, I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. I really don't understand the perspective of someone who can't think of even one good reason why they would ever want to edit history. You've never accidentally committed a password to repo, or had to respond to a takedown request?

wyoung2 7y ago
> sometimes I don't care about history and I'm just trying to coordinate developers across timelines The fact that Fossil preserves history does not prevent you from coordinating with people across timelines. It is rather the whole point of a DVCS. > conflating a workflow decision with a moral failing I think it's fairer to say that we don't think a data repository is any place for lies of any sort, even white lies. > I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. Here, it means someone can say "this happened at some point in the past," and it's just plain wrong. That isn't always an important thing. Most filesystems and databases operate on the same principle, presenting only the current truth, not any past truth. Yet, we also have snapshotting in DBMSes and filesystems, because it's often very useful to be able to say, "This was the state of the system as of 2020.02.04." You don't need a snapshotting filesystem for everything, and you don't need Fossil for everything, but it sure is nice to have ready access to both when needed. > You've never accidentally committed a password to repo, or had to respond to a takedown request? Fossil has shunning for that: https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki And no, shunning is nothing at all like rebase, which should be clear from the article. Fossil also has the `amend` command: http://fossil-scm.org/fossil/help?cmd=amend http://fossil-scm.org/fossil/help?cmd=amend And no, it is also not like rebase, because it only adds to the project history, it never destroys information.
- danShumway 7y ago
  My understanding is that shunning is blacklisting specific artifacts. That's nice, but I don't understand how that solves the problem. When I revise history in Git, even if it's just doing something as simple as removing sensitive information, I often need to replace that information, either through new commits, or by introducing minor edits to surrounding commits. I could add those changes on top of my current HEAD, but then checkouts of old versions would be broken. On the other hand, if I can just replay my commits while inserting extra code, I'll end up with something that's pretty close to my original history, with just the offending information excluded/replaced. That carries the cost that people will need to force pull my repo, but at least the repo history will still roughly correspond to what development looked like, rather than being out-of-order and mostly impossible to build except for at my current HEAD. As a followup question, what do you do if the sensitive information you need to exclude is in a commit message? `amend` won't help you, since it's not destroying information. Do you shun that commit and then... what? It just seems like destroying information isn't enough unless you can also replace it? > Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. I appreciate this -- I like having multiple tools for different purposes. I don't see a problem with having a VC that focuses on auditability, or having one that goes in a radically different direction from Git. Fossil has very interesting ideas, which is why I try to pay it some attention whenever I see it mentioned or linked to. However, whenever I follow those links and start digging deeper into the philosophy behind its design decisions, inevitably the conversation changes from, "here's our alternative approach to Git" to "what Git does is fundamentally wrong". It's not, "Fossil doesn't have this problem because we eschew rebasing", it's "why would anyone rebase?" (Nearly) all architectural decisions have good and bad consequences. Sometimes those consequences are imbalanced, so we have heuristics that can say things like, "often X is a bad idea." That's fine. More harmfully, sometimes people extend heuristics into rules that say, "it's never a good idea to do X". Programming rules are usually wrong. But programming ideologies the worst, because they say, "there is something mentally or morally wrong with a person who would do X". This is toxic for the reasons that Fossil devs already mention in their documentation: > programmers should avoid linking their code with their sense of self Programming ideologies explicitly encourage developers to have egos, because ideology conflates architectural decisions and workflow processes with individual worth. Programming ideologies make it harder for people to grow as programmers, because they tie intellectual growth to fears about being wrong. They're completely toxic. And is Fossil's documentation promoting an ideology? I'm guessing that you'd disagree with me on this, but my take is that when Fossil's official documentation says things like: > Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative. or > It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits. That's not designing a focused tool to support specific heuristics, or making a case that, "sometimes strict auditability is important". That's just trolling for fights.
kazinator 7y ago
I have no interest in Fossil because it stores stuff in sqlite databases instead of the filesystem which I think is a stupid approach. I'm also not interested in version control systems that are dragging along a wiki and bug tracker. I just want a C program in /usr/bin that does version control.
- wyoung2 7y ago
  SQLite can be considerably faster than the filesystem: https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html If you think your filesystem-based Git repo is easy to manipulate, go poking around in there, and what you'll find is a bespoke one-off pile-of-files database! Given a choice between Git's DB and SQLite, I put more trust into SQLite. > I just want a C program in /usr/bin that does version control. ...which Git doesn't provide. Git is hundreds of files scattered all over your filesystem, a large number of which aren't C binaries anyway, and of those that are, only one of them is the front-end program sitting in /usr/bin, whereas Fossil can be built to a single static executable in /usr/bin. And if you can't build Fossil statically on your system, it's likely due to an OS limitation rather than something about Fossil itself, as on RHEL where they've made fully static linking rather difficult in the past few releases. Getting back to Git, large chunks of Git are written in POSIX shell, Perl, Python, and Tcl/Tk. Almost all of Fossil is written in C, and the rest of the code is embedded within that binary running under built-in interpreters rather than depending on platform interpreters. This has nice knock-on effects, one of which is that Fossil is truly native on Windows, whereas you have to drag along a Linux portability environment to run Git on Windows. Another is that Fossil plays nicely with chroot/jail/container technology. > I'm also not interested in version control systems that are dragging along a wiki and bug tracker. Not a GitHub or GitLab user, then, I'm guessing?
  - kazinator 7y ago
    SQLite: isn't that that pile of garbage that eats people's Firefox settings, requiring a periodic "refresh"? > Not a GitHub or GitLab user, then, I'm guessing? Absolutely not.
GoblinSlayer 7y ago
>You've never accidentally committed a password to repo You mean your password is something funny? In that case random.org can help you with password generation.

wyoung2 7y ago

> sometimes I don't care about history and I'm just trying to coordinate developers across timelines The fact that Fossil preserves history does not prevent you from coordinating with people across timelines. It is rather the whole point of a DVCS. > conflating a workflow decision with a moral failing I think it's fairer to say that we don't think a data repository is any place for lies of any sort, even white lies. > I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. Here, it means someone can say "this happened at some point in the past," and it's just plain wrong. That isn't always an important thing. Most filesystems and databases operate on the same principle, presenting only the current truth, not any past truth. Yet, we also have snapshotting in DBMSes and filesystems, because it's often very useful to be able to say, "This was the state of the system as of 2020.02.04." You don't need a snapshotting filesystem for everything, and you don't need Fossil for everything, but it sure is nice to have ready access to both when needed. > You've never accidentally committed a password to repo, or had to respond to a takedown request? Fossil has shunning for that: https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki And no, shunning is nothing at all like rebase, which should be clear from the article. Fossil also has the `amend` command: http://fossil-scm.org/fossil/help?cmd=amend http://fossil-scm.org/fossil/help?cmd=amend And no, it is also not like rebase, because it only adds to the project history, it never destroys information.

danShumway 7y ago
My understanding is that shunning is blacklisting specific artifacts. That's nice, but I don't understand how that solves the problem. When I revise history in Git, even if it's just doing something as simple as removing sensitive information, I often need to replace that information, either through new commits, or by introducing minor edits to surrounding commits. I could add those changes on top of my current HEAD, but then checkouts of old versions would be broken. On the other hand, if I can just replay my commits while inserting extra code, I'll end up with something that's pretty close to my original history, with just the offending information excluded/replaced. That carries the cost that people will need to force pull my repo, but at least the repo history will still roughly correspond to what development looked like, rather than being out-of-order and mostly impossible to build except for at my current HEAD. As a followup question, what do you do if the sensitive information you need to exclude is in a commit message? `amend` won't help you, since it's not destroying information. Do you shun that commit and then... what? It just seems like destroying information isn't enough unless you can also replace it? > Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. I appreciate this -- I like having multiple tools for different purposes. I don't see a problem with having a VC that focuses on auditability, or having one that goes in a radically different direction from Git. Fossil has very interesting ideas, which is why I try to pay it some attention whenever I see it mentioned or linked to. However, whenever I follow those links and start digging deeper into the philosophy behind its design decisions, inevitably the conversation changes from, "here's our alternative approach to Git" to "what Git does is fundamentally wrong". It's not, "Fossil doesn't have this problem because we eschew rebasing", it's "why would anyone rebase?" (Nearly) all architectural decisions have good and bad consequences. Sometimes those consequences are imbalanced, so we have heuristics that can say things like, "often X is a bad idea." That's fine. More harmfully, sometimes people extend heuristics into rules that say, "it's never a good idea to do X". Programming rules are usually wrong. But programming ideologies the worst, because they say, "there is something mentally or morally wrong with a person who would do X". This is toxic for the reasons that Fossil devs already mention in their documentation: > programmers should avoid linking their code with their sense of self Programming ideologies explicitly encourage developers to have egos, because ideology conflates architectural decisions and workflow processes with individual worth. Programming ideologies make it harder for people to grow as programmers, because they tie intellectual growth to fears about being wrong. They're completely toxic. And is Fossil's documentation promoting an ideology? I'm guessing that you'd disagree with me on this, but my take is that when Fossil's official documentation says things like: > Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative. or > It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits. That's not designing a focused tool to support specific heuristics, or making a case that, "sometimes strict auditability is important". That's just trolling for fights.

kazinator 7y ago

I have no interest in Fossil because it stores stuff in sqlite databases instead of the filesystem which I think is a stupid approach. I'm also not interested in version control systems that are dragging along a wiki and bug tracker. I just want a C program in /usr/bin that does version control.

wyoung2 7y ago
SQLite can be considerably faster than the filesystem: https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html If you think your filesystem-based Git repo is easy to manipulate, go poking around in there, and what you'll find is a bespoke one-off pile-of-files database! Given a choice between Git's DB and SQLite, I put more trust into SQLite. > I just want a C program in /usr/bin that does version control. ...which Git doesn't provide. Git is hundreds of files scattered all over your filesystem, a large number of which aren't C binaries anyway, and of those that are, only one of them is the front-end program sitting in /usr/bin, whereas Fossil can be built to a single static executable in /usr/bin. And if you can't build Fossil statically on your system, it's likely due to an OS limitation rather than something about Fossil itself, as on RHEL where they've made fully static linking rather difficult in the past few releases. Getting back to Git, large chunks of Git are written in POSIX shell, Perl, Python, and Tcl/Tk. Almost all of Fossil is written in C, and the rest of the code is embedded within that binary running under built-in interpreters rather than depending on platform interpreters. This has nice knock-on effects, one of which is that Fossil is truly native on Windows, whereas you have to drag along a Linux portability environment to run Git on Windows. Another is that Fossil plays nicely with chroot/jail/container technology. > I'm also not interested in version control systems that are dragging along a wiki and bug tracker. Not a GitHub or GitLab user, then, I'm guessing?
- kazinator 7y ago
  SQLite: isn't that that pile of garbage that eats people's Firefox settings, requiring a periodic "refresh"? > Not a GitHub or GitLab user, then, I'm guessing? Absolutely not.

GoblinSlayer 7y ago

>You've never accidentally committed a password to repo You mean your password is something funny? In that case random.org can help you with password generation.