10 ms·

Fossil Versus Git

104 points by dfox 16y ago

andrewvc 16y ago
Look, new projects should have these pages, and they SHOULD be passionate and biased. However, shit like this makes me stop reading: "Git has a huge user community. If following the herd and being like everybody else is important to you, then you should choose Git."
- steevdave 16y ago
  I logged in to make the same comment. If you want someone to use your product, the best way to do that isn't to call them sheep
  - Johngibb 16y ago
    I agree... I think that making the argument "try fossil because no one else uses it" is just as bad as recommending using git because everyone does. Why not judge it on it's merits?
    - jasonwatkinspdx 16y ago
      Wide usage is a merit. If you know git you can contribute to any project on github more easily. That is an advantage, though it would be utterly foolish to make your choice solely on this point.
- wccrawford 16y ago
  Agreed. Having a small community and not being well-known are not advantages. They try to say that your voice will be comparatively louder and you'll get more attention from the developers, but in a large community, you get attention from the community as well. The only thing you can get from using an unpopular project is an adrenaline rush from living on the edge.
  - stonemetal 16y ago
    Having a small community and not being well-known are not advantages. I am not sure I can agree with this. Smaller communities are often nicer. Think of all the talk around here of growing pains, loss of niceness, comparisons to Reddit or Dig, eternal September, etc. that have come about as the community grows.
    - gabrielroth 16y ago
      That's one way in which a discussion community like HN is different from an open-source product-user community.
      - stonemetal 16y ago
        Open source projects have a very similar problem. When there were 20 people in the Linux community they could all be considered kernel hackers and communicate amongst themselves, now that there are millions they can't assume every member of the community is a kernel hacker, the 'kernel hacker' ability of the average community member has fallen.
- wladimir 16y ago
  Oh no, not another SCM. My head is already bursting from learning Hg and Git... Also I don't think "lack of rebase" is a feature. If you don't want it in git, just forbid using it for your project. However, if you want to maintain a patch-set outside of a project it's the best thing since sliced bread.
  - gecko 16y ago
    Fossil's solution to that are private branches and stashes. That said, I'm with you in preferring rebasing for this kind of thing. (And I'm not even a Git user; I'm pretty wedded to Mercurial.)
    - StavrosK 16y ago
      I used to use bzr, then I used git and was blown away by the speed. I switched to it, still learning the (very hairy) commands, but really enjoying the speed. One day, I tried hg by chance and discovered it was as fast as git and as sensible as bar :( Now I have no idea what to use.
- chc 16y ago
  It also backs this point up with yet another abuse of the most misquoted poem ever, Robert Frost's "The Road Not Taken." The poem isn't actually in praise of making unusual choices — it's about rationalizing the choices we make so that they seem more intelligent and important than they actually were. In the text of the poem, the narrator goes to great lengths to make it clear that he can't tell any difference between the paths in front of him. So he decides to choose one arbitrarily, and tells us that years from now, he'll tell people that he took this little-traveled road and that set the course of his life.
  - gjm11 16y ago
    He kinda contradicts himself. "Then took the other, as just as fair, / And having perhaps the better claim, / Because it was grassy and wanted wear;" seems to imply that the one he took was indeed "less traveled"; but then, immediately, "Though as for that the passing there / Had worn them really about the same,". It doesn't seem to me that there's any Right Answer to the question: Are we supposed to understand that the path he took really was less-travelled, or not? My reading of the last stanza differs from yours: he's not saying that he'll tell people, falsely, that it set the course of his life; he's saying that although he couldn't see any good reason for choosing one over the other, as his life goes on it'll turn out that it made a big difference. The thing that intrigues me about this poem (which, actually, I don't much care for despite its fame) is the title. "The road not taken". That's not the perhaps-less-worn path he did take, it's the other one. Without that title, if you asked me which path was more the subject of the poem I'd have said without hesitation: the one he took, which "has made all the difference". But no: the spotlight is on that sigh with which Frost will be telling the story, the regret (if that's the right word) that he couldn't try them both. I think.
    - chc 16y ago
      It doesn't seem like a real contradiction — it can be easily harmonized as an ironic way of saying they were identical, but he wanted there to be some difference. From the description, can you tell me which road he took? I agree with you on the title though. It puts a really nice spin on the poem.
- mgkimsal 16y ago
  "following the herd"? Yeah, git's had a lot of adoption (methinks primarily due to github), but I work with loads of people who are just getting up to speed with subversion. VCS of any type gives them a headache - "distributed" is even worse. Some client's I worked with in 2010 had no version control at all. "Following the herd" seems a little myopic. :)
- rahoulb 16y ago
  The real problem with that statement is that version control doesn't exist in isolation. If you're the only person using Fossil it's useless to you (I hate git but I have to work with others)
ognyankulev 16y ago
Some NetBSD are considering moving to Fossil. It's notable that Fossil's license is BSD while Git and Mercurial are GPLed. Some interesting pages pop up while search "NetBSD Fossil", like http://www.sonnenberger.org/ http://www.sonnenberger.org/ or interesting quote from Fossil's author in http://mail-index.netbsd.org/tech-repository/2010/01/18/msg000350.html http://mail-index.netbsd.org/tech-repository/2010/01/18/msg0... : "I suppose my biggest concern with Fossil and NetBSD is how Fossil might scale. We use Fossil on projects with a 1GB or larger check-out and with thousands and thousands of files. But I didn't really design fossil for truly huge projects."
teh 16y ago
Does anyone know whether fossil has a staging area? I tried but could not find it. Google didn't really help either.
- gecko 16y ago
  Fossil does not have a staging area. Instead, like Mercurial, it encourages you to stash things you do not plan to commit.
  - etherealG 16y ago
    if you stash everything you're not committing, then the working copy becomes the staging area, and the stash becomes the working copy. how is that any different? seems to me both systems have a method of choosing what to commit, in git you can choose to stash or stage, in the others you can only stash since they "don't have a staging area". git++ for having both options.
    - prodigal_erik 16y ago
      Git has many commands which allow fine-grained manipulation of the staging area; stashes are a crude afterthought in comparison. The problem is that highly encouraged workflows like "git add --patch" inevitably lead to toxic commits which were never tested because they never truly existed in the workspace.
      - hammerdr 16y ago
        Commits aren't dangerous until you push them. You can very easily rebase out a committed patch after you've tested it.
        etherealG 16y ago
        with great power comes great responsibility :)
  - philwelch 16y ago
click170 16y ago
IMO the "Sharding versus Replicating" section sounds a little bit like someone is trying to sell me on a centralized VCS after I've already switched to and enjoy DVCS. And further down in the same section, it sounds like the author has confused Git itself, with the way Git is used developing the Linux kernel. Just because the Linux kernel devs use Git in a particular way doesn't mean Git encourages any one particular model over another. Does anyone know of a more technically accurate and less biased comparison?
- jwecker 16y ago
  WRT selling you on centralized VCS after you've switched to and enjoy DVCS: That was my immediate reaction, but I realized that there is a third thing. In a way, a git-like DVCS in most workflows still retains some of its 'centralized' state - that is, some repositories are the only repositories with certain branches etc. and often there is a specific repository on a server that has all branches "that matter" (such as a github account). As mentioned, Kernel developers need this to reduce clutter/noise and establish arbitrary hierarchies (that are, in a sense, centralized). This "third thing" is, in a way, even more decentralized than old-school CVS/SVN- in that all repositories truly become equal. I'm not saying it's better than git-style-DVCS- it's certainly not if you need an ad-hoc high branch-volume hierarchy- but I do think that it's an underdeveloped use-case that's neither centralized nor adhoc distributed that might (maybe not as Fossil per se) be very useful to many workflows. Put another way- how often do git workflows have you push/pull from multiple remotes when you're ready to deploy (or at all)? In the vast majority of workflows that I've seen and used you generally have one authoritative remote. Something like Fossil would make it so that a push/pull to any remote is effectively the same thing.
Griever 16y ago
I'm all for competition, but how do they come across saying that Git is complex while Fossil is intuitive? Is it possible to still be intuitive while still being a "complex" system? I'm not exactly a Git master, but I have had absolutely no troubles using it after getting everything setup.
TheBoff 16y ago
The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems like bloated: they should be separate things, even if they're interconnected imo.
- cpenner461 16y ago
  This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
  - iloveponies 16y ago
    The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
    - bch 16y ago
      The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
    - stonemetal 16y ago
      I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.
philwelch 16y ago
"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.
- zem 16y ago
  "github in a box" is a superb tagline, though. that was my favourite bit in that article.
  - mnutt 16y ago
    Given a pile of cash, you can actually buy "github in a box": http://fi.github.com/ http://fi.github.com/ I believe it's JRuby-based.
    - philwelch 16y ago
      It is JRuby-based, and they only give you a compiled binary, and it's weeks to months behind the public GitHub site. Aside from those issues, it's really quite nice.
- andos 16y ago
  Have you ever tried to set up a Gitorious box? Not that it's difficult (it is) but it is a complete waste of people's time. If I want to fiddle with every aspect of my development tools, maybe I'm not Fossil's target. Next time I need to set a small coding project (I attend a few OSS hackfests every year), I'll definitely consider Fossil instead of git.
  - philwelch 16y ago
    Have you ever tried to set up a Gitorious box? No, I just use GitHub. Is there a hosted Fossil service that's as easy to use?
js2 16y ago
Fossil is a great little SCM, written by the author of SQLite. This is probably the most controversial page on the fossil-scm.org site. It is intended, I think, to be provocative - don't take the bait. :) Instead, explore the other documentation on the site and see whether it's an SCM for you. Zed Shaw wrote a perfectly reasonable post about why he uses it: http://sheddingbikes.com/posts/1276624594.html http://sheddingbikes.com/posts/1276624594.html Discussion: http://news.ycombinator.com/item?id=1433387 http://news.ycombinator.com/item?id=1433387 Also http://news.ycombinator.com/item?id=809493 http://news.ycombinator.com/item?id=809493
- jodrellblank 16y ago
  When did Zed Shaw write that? I can't see a date tag on the entry; He uses Fossil "these days", is that 2011 or 2006?
  - askedrelic 16y ago
    Looks like the blog url is a timestamp, 1276624594. ruin:~$ date -r 1276624594 Tue Jun 15 13:56:34 EDT 2010
pyninja 16y ago
This does not make me interested in Fossil.
- swaits 16y ago
  That's too bad. Though I mostly use mercurial, when it's appropriate and I get to choose, I've played with fossil and it is quite a nice package. Super easy to setup, fully featured, easy to use, and does what I want. Before you shitcan the whole idea, why not play with it for a few minutes?
  - nimrody 16y ago
    It would help if at least Fossil could use a Git repository (similar to the git plugin for Mercurial). No point in having different projects using multiple version control systems.
    - __david__ 16y ago
      There is when they have significantly different properties/workflows. I happen to think Darcs is supremely good for web development (probably not at facebook scale though)--it's the triviality with which you can cherry-pick patches that makes it wonderful to fast track bug fixes up to the live site while sitting on bigger, more untested changes. I use Git when I'm releasing binaries to people (because I like its tagging better) or when I have to track some upstream code and merge in some local changes.
mdpm 16y ago
... or just go install your own gitorius, and continue benefiting from all the tooling support you already enjoy.
jwecker 16y ago
"The lack of a 'rebase' function is considered a feature of Fossil, not a bug." It's not as if rebase is commonly used. It's there for those rare instances when you, say, remove a file that it turns out you don't have the copyright for and need to purge it completely, or that huge binary file some newb (ok, it was me) committed a while back that's not needed and makes cloning take 10 minutes. Fossil looks really exciting to me- I've used git a ton and like it but don't really delude myself into thinking it can't be disrupted. But, seriously, you're missing a critical feature; instead of trying to patronize your would-be future users by defensively stating that it's a "good thing and we're proud of this missing functionality"- you could simply state something along the lines of "In general we think not having the equivalent of rebase is a good thing, but should you seriously need something like it, this is opensource and we'd love for you to contribute..." etc. [Edit: I'm referring to git-filter-branch etc. to remove those things, not the rebase command per se, but in context of the original page's "Immutable==good" argument I interchanged the two]
- avar 16y ago
  It's not as if rebase is commonly used. This is widly incorrect. Powerusers of Git use rebase extensively, pretty much every patch that makes it into Git itself has been rebased at least half a dozen times. I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages. I wouldn't use any SCM tool that wouldn't give me this functionality. The result of recording all history permanently is that users will just not commit their incomplete work, meaning that it'll be in their working tree instead of tracked in some form by the repository.
  - Scaevolus 16y ago
    Agreed, without rebasing the history for projects with lots of developers quickly becomes a mess. > Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. I'm not sure how keeping garbage like "oops, fix typo" out of history is lying to your fellow developers-- a VCS should be aiding development, not forcing others to see your little mistakes.
malkia 16y ago
Github to git, is like Tarpit to fossil :) Too bad tarpit.com is taken :(
- dgroves 16y ago
  how about labrea.com then?
jrockway 16y ago
Git features the "rebase" command which can be used to change the sequence of check-ins in the repository. Rebase can be used to "clean up" a complex sequence of check-ins to make their intent easier for others to understand. From another point of view, rebase can be used to "rewrite history" - to do what Winston Smith did for a living in Orwell's novel 1984. This is FUD. Git never erases history; it merely moves mutable refs around. When you rebase a branch called "master", nothing is rewritten: a new immutable commit history is created, and the ref "master" is moved from pointing at the old history to pointing at the new history. The old history still exists in all its glory at "master@{0}". (And when you change that, it goes to master@{1}, and so on.) If git didn't have the concept of refs, then this would never even worry anyone. Once you have commit ab387df, it's refers to the same sequence of changes for all eternity. What master points to may change out from under you, but the history never goes anywhere. The only way to "rewrite history" is to delete every copy of the repository ever made, which is exactly how you would rewrite history with Fossil or Subversion or anything. (And now, if I may, a digression. I've noticed that the "rewriting history" aspect of Git makes for a good personality test. It's strongly polarizing -- the people that think source control is designed to be documentation love it, and the people that think source control is an audit mechanism hate it. Control freaks hate git, and long-haired hippies seem to love it.)
- hasenj 16y ago
  re: digression I don't use rebase and I can't say that I like it, but that doesn't make me hate git. I commit all my crappy and stupid intermediate code (for my personal projects).
  - jrockway 16y ago
    Do you ever use the change history for anything? When you keep the change history clean, it's a lot easier to answer questions like "why did I do that?", and it's a lot easier to explore topic branches and back out bad design ideas. If the history is messy, removing bad changes is about as difficult as opening up every file and removing the changes you don't want. In other words -- error prone.
- 16y ago
cageface 16y ago
Fossil would have to be much better than Git for me to take a serious look. I'm not interested in micro-optimizing every single piece of my toolkit. Git is the DVCS with all the momentum and mindshare and it does what I need it to do. I have bigger fish to fry.
mmavnn 16y ago
Fossil is also one of the few options when you're working on windows without admin rights. Saved me from being completely without vcs in a couple of previous job posts.

104 points by dfox 16y ago

Look, new projects should have these pages, and they SHOULD be passionate and biased. However, shit like this makes me stop reading: "Git has a huge user community. If following the herd and being like everybody else is important to you, then you should choose Git."

steevdave 16y ago
I logged in to make the same comment. If you want someone to use your product, the best way to do that isn't to call them sheep
- Johngibb 16y ago
  I agree... I think that making the argument "try fossil because no one else uses it" is just as bad as recommending using git because everyone does. Why not judge it on it's merits?
  - jasonwatkinspdx 16y ago
    Wide usage is a merit. If you know git you can contribute to any project on github more easily. That is an advantage, though it would be utterly foolish to make your choice solely on this point.
wccrawford 16y ago
Agreed. Having a small community and not being well-known are not advantages. They try to say that your voice will be comparatively louder and you'll get more attention from the developers, but in a large community, you get attention from the community as well. The only thing you can get from using an unpopular project is an adrenaline rush from living on the edge.
- stonemetal 16y ago
  Having a small community and not being well-known are not advantages. I am not sure I can agree with this. Smaller communities are often nicer. Think of all the talk around here of growing pains, loss of niceness, comparisons to Reddit or Dig, eternal September, etc. that have come about as the community grows.
  - gabrielroth 16y ago
    That's one way in which a discussion community like HN is different from an open-source product-user community.
    - stonemetal 16y ago
      Open source projects have a very similar problem. When there were 20 people in the Linux community they could all be considered kernel hackers and communicate amongst themselves, now that there are millions they can't assume every member of the community is a kernel hacker, the 'kernel hacker' ability of the average community member has fallen.
wladimir 16y ago
Oh no, not another SCM. My head is already bursting from learning Hg and Git... Also I don't think "lack of rebase" is a feature. If you don't want it in git, just forbid using it for your project. However, if you want to maintain a patch-set outside of a project it's the best thing since sliced bread.
- gecko 16y ago
  Fossil's solution to that are private branches and stashes. That said, I'm with you in preferring rebasing for this kind of thing. (And I'm not even a Git user; I'm pretty wedded to Mercurial.)
  - StavrosK 16y ago
    I used to use bzr, then I used git and was blown away by the speed. I switched to it, still learning the (very hairy) commands, but really enjoying the speed. One day, I tried hg by chance and discovered it was as fast as git and as sensible as bar :( Now I have no idea what to use.
chc 16y ago
It also backs this point up with yet another abuse of the most misquoted poem ever, Robert Frost's "The Road Not Taken." The poem isn't actually in praise of making unusual choices — it's about rationalizing the choices we make so that they seem more intelligent and important than they actually were. In the text of the poem, the narrator goes to great lengths to make it clear that he can't tell any difference between the paths in front of him. So he decides to choose one arbitrarily, and tells us that years from now, he'll tell people that he took this little-traveled road and that set the course of his life.
- gjm11 16y ago
  He kinda contradicts himself. "Then took the other, as just as fair, / And having perhaps the better claim, / Because it was grassy and wanted wear;" seems to imply that the one he took was indeed "less traveled"; but then, immediately, "Though as for that the passing there / Had worn them really about the same,". It doesn't seem to me that there's any Right Answer to the question: Are we supposed to understand that the path he took really was less-travelled, or not? My reading of the last stanza differs from yours: he's not saying that he'll tell people, falsely, that it set the course of his life; he's saying that although he couldn't see any good reason for choosing one over the other, as his life goes on it'll turn out that it made a big difference. The thing that intrigues me about this poem (which, actually, I don't much care for despite its fame) is the title. "The road not taken". That's not the perhaps-less-worn path he did take, it's the other one. Without that title, if you asked me which path was more the subject of the poem I'd have said without hesitation: the one he took, which "has made all the difference". But no: the spotlight is on that sigh with which Frost will be telling the story, the regret (if that's the right word) that he couldn't try them both. I think.
  - chc 16y ago
    It doesn't seem like a real contradiction — it can be easily harmonized as an ironic way of saying they were identical, but he wanted there to be some difference. From the description, can you tell me which road he took? I agree with you on the title though. It puts a really nice spin on the poem.
mgkimsal 16y ago
"following the herd"? Yeah, git's had a lot of adoption (methinks primarily due to github), but I work with loads of people who are just getting up to speed with subversion. VCS of any type gives them a headache - "distributed" is even worse. Some client's I worked with in 2010 had no version control at all. "Following the herd" seems a little myopic. :)
rahoulb 16y ago
The real problem with that statement is that version control doesn't exist in isolation. If you're the only person using Fossil it's useless to you (I hate git but I have to work with others)

ognyankulev 16y ago

Some NetBSD are considering moving to Fossil. It's notable that Fossil's license is BSD while Git and Mercurial are GPLed. Some interesting pages pop up while search "NetBSD Fossil", like http://www.sonnenberger.org/ http://www.sonnenberger.org/ or interesting quote from Fossil's author in http://mail-index.netbsd.org/tech-repository/2010/01/18/msg000350.html http://mail-index.netbsd.org/tech-repository/2010/01/18/msg0... : "I suppose my biggest concern with Fossil and NetBSD is how Fossil might scale. We use Fossil on projects with a 1GB or larger check-out and with thousands and thousands of files. But I didn't really design fossil for truly huge projects."

teh 16y ago

Does anyone know whether fossil has a staging area? I tried but could not find it. Google didn't really help either.

gecko 16y ago
Fossil does not have a staging area. Instead, like Mercurial, it encourages you to stash things you do not plan to commit.
- etherealG 16y ago
  if you stash everything you're not committing, then the working copy becomes the staging area, and the stash becomes the working copy. how is that any different? seems to me both systems have a method of choosing what to commit, in git you can choose to stash or stage, in the others you can only stash since they "don't have a staging area". git++ for having both options.
  - prodigal_erik 16y ago
    Git has many commands which allow fine-grained manipulation of the staging area; stashes are a crude afterthought in comparison. The problem is that highly encouraged workflows like "git add --patch" inevitably lead to toxic commits which were never tested because they never truly existed in the workspace.
    - hammerdr 16y ago
      Commits aren't dangerous until you push them. You can very easily rebase out a committed patch after you've tested it.
      - etherealG 16y ago
        with great power comes great responsibility :)
- philwelch 16y ago

click170 16y ago

IMO the "Sharding versus Replicating" section sounds a little bit like someone is trying to sell me on a centralized VCS after I've already switched to and enjoy DVCS. And further down in the same section, it sounds like the author has confused Git itself, with the way Git is used developing the Linux kernel. Just because the Linux kernel devs use Git in a particular way doesn't mean Git encourages any one particular model over another. Does anyone know of a more technically accurate and less biased comparison?

jwecker 16y ago
WRT selling you on centralized VCS after you've switched to and enjoy DVCS: That was my immediate reaction, but I realized that there is a third thing. In a way, a git-like DVCS in most workflows still retains some of its 'centralized' state - that is, some repositories are the only repositories with certain branches etc. and often there is a specific repository on a server that has all branches "that matter" (such as a github account). As mentioned, Kernel developers need this to reduce clutter/noise and establish arbitrary hierarchies (that are, in a sense, centralized). This "third thing" is, in a way, even more decentralized than old-school CVS/SVN- in that all repositories truly become equal. I'm not saying it's better than git-style-DVCS- it's certainly not if you need an ad-hoc high branch-volume hierarchy- but I do think that it's an underdeveloped use-case that's neither centralized nor adhoc distributed that might (maybe not as Fossil per se) be very useful to many workflows. Put another way- how often do git workflows have you push/pull from multiple remotes when you're ready to deploy (or at all)? In the vast majority of workflows that I've seen and used you generally have one authoritative remote. Something like Fossil would make it so that a push/pull to any remote is effectively the same thing.

Griever 16y ago

I'm all for competition, but how do they come across saying that Git is complex while Fossil is intuitive? Is it possible to still be intuitive while still being a "complex" system? I'm not exactly a Git master, but I have had absolutely no troubles using it after getting everything setup.

TheBoff 16y ago

The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems like bloated: they should be separate things, even if they're interconnected imo.

cpenner461 16y ago
This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
- iloveponies 16y ago
  The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
  - bch 16y ago
    The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
  - stonemetal 16y ago
    I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.

philwelch 16y ago

"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.

zem 16y ago
"github in a box" is a superb tagline, though. that was my favourite bit in that article.
- mnutt 16y ago
  Given a pile of cash, you can actually buy "github in a box": http://fi.github.com/ http://fi.github.com/ I believe it's JRuby-based.
  - philwelch 16y ago
    It is JRuby-based, and they only give you a compiled binary, and it's weeks to months behind the public GitHub site. Aside from those issues, it's really quite nice.
andos 16y ago
Have you ever tried to set up a Gitorious box? Not that it's difficult (it is) but it is a complete waste of people's time. If I want to fiddle with every aspect of my development tools, maybe I'm not Fossil's target. Next time I need to set a small coding project (I attend a few OSS hackfests every year), I'll definitely consider Fossil instead of git.
- philwelch 16y ago
  Have you ever tried to set up a Gitorious box? No, I just use GitHub. Is there a hosted Fossil service that's as easy to use?

js2 16y ago

Fossil is a great little SCM, written by the author of SQLite. This is probably the most controversial page on the fossil-scm.org site. It is intended, I think, to be provocative - don't take the bait. :) Instead, explore the other documentation on the site and see whether it's an SCM for you. Zed Shaw wrote a perfectly reasonable post about why he uses it: http://sheddingbikes.com/posts/1276624594.html http://sheddingbikes.com/posts/1276624594.html Discussion: http://news.ycombinator.com/item?id=1433387 http://news.ycombinator.com/item?id=1433387 Also http://news.ycombinator.com/item?id=809493 http://news.ycombinator.com/item?id=809493

jodrellblank 16y ago
When did Zed Shaw write that? I can't see a date tag on the entry; He uses Fossil "these days", is that 2011 or 2006?
- askedrelic 16y ago
  Looks like the blog url is a timestamp, 1276624594. ruin:~$ date -r 1276624594 Tue Jun 15 13:56:34 EDT 2010

pyninja 16y ago

This does not make me interested in Fossil.

swaits 16y ago
That's too bad. Though I mostly use mercurial, when it's appropriate and I get to choose, I've played with fossil and it is quite a nice package. Super easy to setup, fully featured, easy to use, and does what I want. Before you shitcan the whole idea, why not play with it for a few minutes?
- nimrody 16y ago
  It would help if at least Fossil could use a Git repository (similar to the git plugin for Mercurial). No point in having different projects using multiple version control systems.
  - __david__ 16y ago
    There is when they have significantly different properties/workflows. I happen to think Darcs is supremely good for web development (probably not at facebook scale though)--it's the triviality with which you can cherry-pick patches that makes it wonderful to fast track bug fixes up to the live site while sitting on bigger, more untested changes. I use Git when I'm releasing binaries to people (because I like its tagging better) or when I have to track some upstream code and merge in some local changes.

mdpm 16y ago

... or just go install your own gitorius, and continue benefiting from all the tooling support you already enjoy.

jwecker 16y ago

"The lack of a 'rebase' function is considered a feature of Fossil, not a bug." It's not as if rebase is commonly used. It's there for those rare instances when you, say, remove a file that it turns out you don't have the copyright for and need to purge it completely, or that huge binary file some newb (ok, it was me) committed a while back that's not needed and makes cloning take 10 minutes. Fossil looks really exciting to me- I've used git a ton and like it but don't really delude myself into thinking it can't be disrupted. But, seriously, you're missing a critical feature; instead of trying to patronize your would-be future users by defensively stating that it's a "good thing and we're proud of this missing functionality"- you could simply state something along the lines of "In general we think not having the equivalent of rebase is a good thing, but should you seriously need something like it, this is opensource and we'd love for you to contribute..." etc. [Edit: I'm referring to git-filter-branch etc. to remove those things, not the rebase command per se, but in context of the original page's "Immutable==good" argument I interchanged the two]

avar 16y ago
It's not as if rebase is commonly used. This is widly incorrect. Powerusers of Git use rebase extensively, pretty much every patch that makes it into Git itself has been rebased at least half a dozen times. I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages. I wouldn't use any SCM tool that wouldn't give me this functionality. The result of recording all history permanently is that users will just not commit their incomplete work, meaning that it'll be in their working tree instead of tracked in some form by the repository.
- Scaevolus 16y ago
  Agreed, without rebasing the history for projects with lots of developers quickly becomes a mess. > Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. I'm not sure how keeping garbage like "oops, fix typo" out of history is lying to your fellow developers-- a VCS should be aiding development, not forcing others to see your little mistakes.

malkia 16y ago

Github to git, is like Tarpit to fossil :) Too bad tarpit.com is taken :(

dgroves 16y ago
how about labrea.com then?

jrockway 16y ago

Git features the "rebase" command which can be used to change the sequence of check-ins in the repository. Rebase can be used to "clean up" a complex sequence of check-ins to make their intent easier for others to understand. From another point of view, rebase can be used to "rewrite history" - to do what Winston Smith did for a living in Orwell's novel 1984. This is FUD. Git never erases history; it merely moves mutable refs around. When you rebase a branch called "master", nothing is rewritten: a new immutable commit history is created, and the ref "master" is moved from pointing at the old history to pointing at the new history. The old history still exists in all its glory at "master@{0}". (And when you change that, it goes to master@{1}, and so on.) If git didn't have the concept of refs, then this would never even worry anyone. Once you have commit ab387df, it's refers to the same sequence of changes for all eternity. What master points to may change out from under you, but the history never goes anywhere. The only way to "rewrite history" is to delete every copy of the repository ever made, which is exactly how you would rewrite history with Fossil or Subversion or anything. (And now, if I may, a digression. I've noticed that the "rewriting history" aspect of Git makes for a good personality test. It's strongly polarizing -- the people that think source control is designed to be documentation love it, and the people that think source control is an audit mechanism hate it. Control freaks hate git, and long-haired hippies seem to love it.)

hasenj 16y ago
re: digression I don't use rebase and I can't say that I like it, but that doesn't make me hate git. I commit all my crappy and stupid intermediate code (for my personal projects).
- jrockway 16y ago
  Do you ever use the change history for anything? When you keep the change history clean, it's a lot easier to answer questions like "why did I do that?", and it's a lot easier to explore topic branches and back out bad design ideas. If the history is messy, removing bad changes is about as difficult as opening up every file and removing the changes you don't want. In other words -- error prone.
16y ago

cageface 16y ago

Fossil would have to be much better than Git for me to take a serious look. I'm not interested in micro-optimizing every single piece of my toolkit. Git is the DVCS with all the momentum and mindshare and it does what I need it to do. I have bigger fish to fry.

mmavnn 16y ago

Fossil is also one of the few options when you're working on windows without admin rights. Saved me from being completely without vcs in a couple of previous job posts.