4 ms·

Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build th

Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it. I don’t want an issue tracker and chat and everything else in my git. And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. Comically, I’d probably use the fossil service if it supported git. Anyone else remember when Google Code only supported mercurial? And they talked about how much better mercurial was than git. And they were right. And no one cared. I hope fossil sticks around because I like more services. But if I was interviewing for a company and they said that I must use fossil, I probably wouldn’t work there. (This is similar to if they said you must use TFS or something else weird) I’ve used so many version controls over the years (vss, cvs, subversion, clearcase, perforce, bitkeeper, tfs, mercurial, manual file system hacks) and I need a really good reason to use something other than git. Making it more complex is not a reason I accept.

rakoo 3y ago
> And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.
- prepend 3y ago
  First, those are bolt-ons and I don’t actually want them tied to the source code management system. Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information. Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll scripts that build out fine on GitHub pages or gitlab pages or whatever. And I can move to any host I want. I don’t want to couple my project’s web site to my source code host. These are “solved” features as far as I’m concerned and these actually bring negative value for me. I don’t want to worry about what kind of forum functionality my scm provides. And I certainly don’t care about pushing my forum from one server to another.
  - rakoo 3y ago
    The mistake is assuming that fossil is simply a source code management system, it is not. Fossil is closer to a collaboration system around source code. If you can live your life without it, good. But if I want to use a GUI with links instead of markdown files in a repo from which I can't click to go to the next article, an ssg and a dependency on Github/Gitlab/whatever host I store my code in, and other tools, then fossil does it all for me right from a single binary that will be the same for everyone.
    - prepend 3y ago
      The article title is git vs fossil. So it’s not just my mistake. Based on the popularity of the projects, it seems the mistake of the fossil team is that they think they are competing with git. I look forward to fossil supporting git and then I might consider using it.
  - sgbeal 3y ago
    > First, those are bolt-ons and I don’t actually want them tied to the source code management system. Anecdote: when Richard first proposed the /chat feature in fossil i was highly skeptical about its utility but (as the fossil project's "JS guy") wrote it anyway. Now, almost 3 years later, we've been using chat 24/7 across multiple fossil-hosted projects and can't imagine doing without it. The majority of the sqlite project's coordination happens via fossil's /chat. Yes, it was bolted on, but it's also become indispensable for us as a feature.
remram 3y ago
> my car won’t start because I’m out of coffee grounds I'd call this a straw man but it's way past that...
- prepend 3y ago
  It’s an allegory, not a strawman.
  - remram 3y ago
    Fossil's source control doesn't break if the issue tracker or wiki is misconfigured or disabled. Just like your imaginary car-with-a-coffee-machine would not fail to drive if it were out of coffee grounds. Saying "I don't want my version control to break because of misconfigured wiki" would have already been a straw man, adding this BS about cars making coffee just makes it more insane of an argument.
    - prepend 3y ago
      I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version. But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about. I love wikis and I love coffee. But I don’t want to have to install a wiki just to use source control. I love used enough systems where stuff breaks because of a particular feature I didn’t know about and certainly don’t want (atlassian) to be wary of things. And while the car / coffee maker allegory is funny, I wouldn’t be surprised if a car does break in the near future because some dumb feature can’t phone home and validate. Or the battery died from some process that kept running and was completely unnecessary.
      - remram 3y ago
        Do you use all of Git's features? Bundles, emailing, git-daemon? Submodules? I wonder if you were aware that git contains an IMAP client.
Skinney 3y ago
If your car followed the unix philosophy you’d have to bring your own radio and AC.
- prepend 3y ago
  Right. It’s a careful balance of what to include and what not to include. I don’t know the exact dividing line for “do one thing” but I think that modularity and composability is important. I like having an AC in my car. But I don’t want AC to be a dependency for my car. I like chaining tools together, but work to minimize the required dependency among tools. I think in principle, it’s good if you can install components separately. So for me git only doing version control is good. If they added a chat feature, I would not want that. If they had a chat module that I could optionally install, maybe.
  - Skinney 3y ago
    Fossil doesn’t have a dependency on chat, forum, wiki or issues. They’re included, part of the same product. But if you don’t want it, then you don’t have to use it. Just like you don’t have to turn on the radio or AC in your car. Just like all the email related stuff in Git. And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. A car without an AC isn’t better to drive than a car with an AC. And, just like a car comes with a radio and AC because you likely want those conviniences, fossil comes with issue tracking and wiki because you’re likely to want that for your project. Don’t have to use it, but it’s there if you do.
    - prepend 3y ago
      > And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. I think this is a philosophical preference. I think they do detract because they make the system more complex. And fossil developers work on that instead of the think I want. So there’s a cost there. Having an AC and radio in a car increases its price. Not by much but by something. If designers didn’t work in the AC, there would be something else they put in. Or the car would be simpler. I definitely want an AC in every car I buy. Maybe a radio. So I don’t mind they they’re bundled. I’m sure the people who want wikis and chat in every repo like it too. Good for them, use it. I wish them the best. I don’t like it and think it detracts from their product. I consider them more like project management or collab software with a custom vcm built in. And so I’d rather prefer some collab stack that uses the best vcm stack I think is out there, git. So they’re on a tough spot because they’d be better off just selling all their GitHub-competitor features without trying to convince people to switch off of git. Just like a car coffee maker company would be better off just making coffee makers they fit into popular cars rather than trying to make a literal car.

rakoo 3y ago

> And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.

prepend 3y ago
First, those are bolt-ons and I don’t actually want them tied to the source code management system. Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information. Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll scripts that build out fine on GitHub pages or gitlab pages or whatever. And I can move to any host I want. I don’t want to couple my project’s web site to my source code host. These are “solved” features as far as I’m concerned and these actually bring negative value for me. I don’t want to worry about what kind of forum functionality my scm provides. And I certainly don’t care about pushing my forum from one server to another.
- rakoo 3y ago
  The mistake is assuming that fossil is simply a source code management system, it is not. Fossil is closer to a collaboration system around source code. If you can live your life without it, good. But if I want to use a GUI with links instead of markdown files in a repo from which I can't click to go to the next article, an ssg and a dependency on Github/Gitlab/whatever host I store my code in, and other tools, then fossil does it all for me right from a single binary that will be the same for everyone.
  - prepend 3y ago
    The article title is git vs fossil. So it’s not just my mistake. Based on the popularity of the projects, it seems the mistake of the fossil team is that they think they are competing with git. I look forward to fossil supporting git and then I might consider using it.
- sgbeal 3y ago
  > First, those are bolt-ons and I don’t actually want them tied to the source code management system. Anecdote: when Richard first proposed the /chat feature in fossil i was highly skeptical about its utility but (as the fossil project's "JS guy") wrote it anyway. Now, almost 3 years later, we've been using chat 24/7 across multiple fossil-hosted projects and can't imagine doing without it. The majority of the sqlite project's coordination happens via fossil's /chat. Yes, it was bolted on, but it's also become indispensable for us as a feature.

remram 3y ago

> my car won’t start because I’m out of coffee grounds I'd call this a straw man but it's way past that...

prepend 3y ago
It’s an allegory, not a strawman.
- remram 3y ago
  Fossil's source control doesn't break if the issue tracker or wiki is misconfigured or disabled. Just like your imaginary car-with-a-coffee-machine would not fail to drive if it were out of coffee grounds. Saying "I don't want my version control to break because of misconfigured wiki" would have already been a straw man, adding this BS about cars making coffee just makes it more insane of an argument.
  - prepend 3y ago
    I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version. But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about. I love wikis and I love coffee. But I don’t want to have to install a wiki just to use source control. I love used enough systems where stuff breaks because of a particular feature I didn’t know about and certainly don’t want (atlassian) to be wary of things. And while the car / coffee maker allegory is funny, I wouldn’t be surprised if a car does break in the near future because some dumb feature can’t phone home and validate. Or the battery died from some process that kept running and was completely unnecessary.
    - remram 3y ago
      Do you use all of Git's features? Bundles, emailing, git-daemon? Submodules? I wonder if you were aware that git contains an IMAP client.

Skinney 3y ago

If your car followed the unix philosophy you’d have to bring your own radio and AC.

prepend 3y ago
Right. It’s a careful balance of what to include and what not to include. I don’t know the exact dividing line for “do one thing” but I think that modularity and composability is important. I like having an AC in my car. But I don’t want AC to be a dependency for my car. I like chaining tools together, but work to minimize the required dependency among tools. I think in principle, it’s good if you can install components separately. So for me git only doing version control is good. If they added a chat feature, I would not want that. If they had a chat module that I could optionally install, maybe.
- Skinney 3y ago
  Fossil doesn’t have a dependency on chat, forum, wiki or issues. They’re included, part of the same product. But if you don’t want it, then you don’t have to use it. Just like you don’t have to turn on the radio or AC in your car. Just like all the email related stuff in Git. And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. A car without an AC isn’t better to drive than a car with an AC. And, just like a car comes with a radio and AC because you likely want those conviniences, fossil comes with issue tracking and wiki because you’re likely to want that for your project. Don’t have to use it, but it’s there if you do.
  - prepend 3y ago
    > And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. I think this is a philosophical preference. I think they do detract because they make the system more complex. And fossil developers work on that instead of the think I want. So there’s a cost there. Having an AC and radio in a car increases its price. Not by much but by something. If designers didn’t work in the AC, there would be something else they put in. Or the car would be simpler. I definitely want an AC in every car I buy. Maybe a radio. So I don’t mind they they’re bundled. I’m sure the people who want wikis and chat in every repo like it too. Good for them, use it. I wish them the best. I don’t like it and think it detracts from their product. I consider them more like project management or collab software with a custom vcm built in. And so I’d rather prefer some collab stack that uses the best vcm stack I think is out there, git. So they’re on a tough spot because they’d be better off just selling all their GitHub-competitor features without trying to convince people to switch off of git. Just like a car coffee maker company would be better off just making coffee makers they fit into popular cars rather than trying to make a literal car.