9 ms·

> That cute rhetoric will not fool anyone. Well, let's see, the Fossil equivalents are: 1. Do nothing at all for a conversion from the SHA-1 to SHA-3 — yes, 3

> That cute rhetoric will not fool anyone. Well, let's see, the Fossil equivalents are: 1. Do nothing at all for a conversion from the SHA-1 to SHA-3 — yes, 3, not 2 as in Git! — because it's automatic for months now and dead easy going back 3 years now. (https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.wiki https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.w...) 2. "fossil diff" 3. "fossil ci" 4. Why are you rebasing in the first place, again? https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...

danShumway 7y ago
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.
kazinator 7y ago
The diatribe against rebasing is stupid. In fact, not having more than one parent is a good thing because you with multiple parents, you don't know what is relevant. The history has turned into a hairball. When you try to navigate back in time, you face forking roads at every step and it turns into a maze walk. The point is valid that when we rebase, we are losing history: the context of where that change was originally parented. However, (1) the history does not matter if the change was parented in some temporary context, like your unpublished changes and (2) the information can be tracked in other ways, such as a Gerrit Change-Id (or something like it) in the commit message. Regarding (1) the extra parent pointers in a merge commit cause retention of garbage. If we do everything with merge instead of rebase, we will never lose any of the temporary commits. If we prepare an unpublished change through numerous rebase operations, all that temporary crap will stay referenced from the head, waste space and confuse other people with irrelevant information when they try to navigate the history.
- wyoung2 7y ago
  > history does not matter if the change was parented in some temporary context It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects. Git users can also hide individual commit messages behind one big combined message, losing part of the project's development history and logical progression. When I pull your repo and build it, and I find that it doesn't build on my system, I don't want to dig through a 500-line merge commit to figure out why you changed this one line from the one that used to build last week, I want the 14-line diff it was part of so I can begin to understand what you were thinking when you committed it. If I later find out that that 14-line change was wrong but the rest of your 500-line merge was fine, I want to be able to back it out with a single command. (In Fossil, it's `fossil merge --backout abcd1234`.) > confuse other people with irrelevant information when they try to navigate the history. How much time do you spend navigating the project's history vs looking at the tip of the current branch? I'd wager that the times you dig back into the history, it's because you are in fact trying to figure out why you got here, which means a trail of detailed breadcrumbs will be more likely helpful than "...and between one week and the next, something changed in commit abcd1234, but we've lost all of its internal context, so we'll be spending next week reconstructing it because Angie's on vacation now."
kazinator 7y ago
Regarding (1), not "everything will work as before". What happens if a Fossil repo that has had SHA3 commits written to it is accessed by old Fossil software before that change was introduced?
- wyoung2 7y ago
  If you try to use Fossil 1.37 — the last 1.x release — to clone a repo that has SHA-3 hashed artifacts in it, it says, "server returned an error - clone aborted". Since 1.37 pre-dates this feature, it can't give a more detailed diagnosis than that. If you have an old clone made from before the transition and try to update it, I'm not sure what it says, since I don't have any of those around any more. It has, after all, been three years since Fossil began to move on this problem, so that it's largely a past issue for us now. This transition time was indeed annoying for us over in Fossil land, but Git's going to have to go through a transition like this, too. The question isn't whether but how long we'll have to wait for it to begin and how long it'll take to complete.
  - kazinator 7y ago
    > Git's going to have to go through a transition like this, too. The moment I can't read new repos with an installation of git 1.6 or 1.7, I'm ditching the garbage and finding something else. Forward and backward compatibility, forever, please!
    - wyoung2 7y ago
      In large measure, you actually can't, since there's a good chance those repos are behind HTTPS-only these days, and those versions of Git will be linked to ancient versions of OpenSSL that won't even talk to modern TLS implementations, the two being unable to agree on a common ciphersuite. Beyond about 10 years, you usually end up freezing old binaries in place along with old data in order to continue manipulating it anyway.

danShumway 7y ago

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.

kazinator 7y ago

The diatribe against rebasing is stupid. In fact, not having more than one parent is a good thing because you with multiple parents, you don't know what is relevant. The history has turned into a hairball. When you try to navigate back in time, you face forking roads at every step and it turns into a maze walk. The point is valid that when we rebase, we are losing history: the context of where that change was originally parented. However, (1) the history does not matter if the change was parented in some temporary context, like your unpublished changes and (2) the information can be tracked in other ways, such as a Gerrit Change-Id (or something like it) in the commit message. Regarding (1) the extra parent pointers in a merge commit cause retention of garbage. If we do everything with merge instead of rebase, we will never lose any of the temporary commits. If we prepare an unpublished change through numerous rebase operations, all that temporary crap will stay referenced from the head, waste space and confuse other people with irrelevant information when they try to navigate the history.

wyoung2 7y ago
> history does not matter if the change was parented in some temporary context It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects. Git users can also hide individual commit messages behind one big combined message, losing part of the project's development history and logical progression. When I pull your repo and build it, and I find that it doesn't build on my system, I don't want to dig through a 500-line merge commit to figure out why you changed this one line from the one that used to build last week, I want the 14-line diff it was part of so I can begin to understand what you were thinking when you committed it. If I later find out that that 14-line change was wrong but the rest of your 500-line merge was fine, I want to be able to back it out with a single command. (In Fossil, it's `fossil merge --backout abcd1234`.) > confuse other people with irrelevant information when they try to navigate the history. How much time do you spend navigating the project's history vs looking at the tip of the current branch? I'd wager that the times you dig back into the history, it's because you are in fact trying to figure out why you got here, which means a trail of detailed breadcrumbs will be more likely helpful than "...and between one week and the next, something changed in commit abcd1234, but we've lost all of its internal context, so we'll be spending next week reconstructing it because Angie's on vacation now."

kazinator 7y ago

Regarding (1), not "everything will work as before". What happens if a Fossil repo that has had SHA3 commits written to it is accessed by old Fossil software before that change was introduced?

wyoung2 7y ago
If you try to use Fossil 1.37 — the last 1.x release — to clone a repo that has SHA-3 hashed artifacts in it, it says, "server returned an error - clone aborted". Since 1.37 pre-dates this feature, it can't give a more detailed diagnosis than that. If you have an old clone made from before the transition and try to update it, I'm not sure what it says, since I don't have any of those around any more. It has, after all, been three years since Fossil began to move on this problem, so that it's largely a past issue for us now. This transition time was indeed annoying for us over in Fossil land, but Git's going to have to go through a transition like this, too. The question isn't whether but how long we'll have to wait for it to begin and how long it'll take to complete.
- kazinator 7y ago
  > Git's going to have to go through a transition like this, too. The moment I can't read new repos with an installation of git 1.6 or 1.7, I'm ditching the garbage and finding something else. Forward and backward compatibility, forever, please!
  - wyoung2 7y ago
    In large measure, you actually can't, since there's a good chance those repos are behind HTTPS-only these days, and those versions of Git will be linked to ancient versions of OpenSSL that won't even talk to modern TLS implementations, the two being unable to agree on a common ciphersuite. Beyond about 10 years, you usually end up freezing old binaries in place along with old data in order to continue manipulating it anyway.