13 ms·

Fossil

207 points by cassepipe 5y ago

SuperSandro2000 5y ago
Do everything but everything mediocre.
umvi 5y ago
Seems like Fossil is more like an alternative to GitHub than Git. Fossil not only tracks code changes but team chat, bug tracking, wikis, etc.
- leetrout 5y ago
  Yes and no. It tracks the issues in the source repo. Everything is an artifact and some artifacts are bugs, technotes, etc https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki This is from the same person who made SQLite.
- simonw 5y ago
  That's the "batteries included" bit!
  - pvg 5y ago
    That's something the submitter made up in the title, it's not how Fossil self-describes.
- josephg 5y ago
  Fossil is an alternative to both git (source control) and github (issues, etc). I think its brilliant having issues tracked in fossil. Part of the promise of github is that the user is in control, since your computer is a first-class citizen of a repository. You have all the code, and all the history on your computer. You can use github, but you don't need github, since its just another node in git's distributed network. But that promise falls apart with issues and pull requests. Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations. Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - You can have a project on both github and gitlab. And you can replicate commits to both. But you can't replicate issues using the same mechanism. Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant.
  - benatkin 5y ago
    That's true. People imagine GitHub provides git, but that's the wrong way of seeing it. They do provide it on your server but the git running on your own computer is from the git project. GitHub does help significantly with the git project, though. Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/ https://git-scm.com/
  - Jach 5y ago
    You're overstating the risks a bit and it's not great to posit implausible motives and means for bad outcomes... Like, Fossil devs could "turn evil", and ship an update that destroys your museum and any copies it can find. Github could "turn evil" without notice, and permanently nuke all of someone or some org's accounts for no good reason and yes, that'd catch a lot of people with their pants down. It's better to first focus on outcomes, not means. Of course anyone actually concerned about losing their github issue data (or having their museums corrupted) should at least be making backups. (And it's not exactly an implausible outcome on its own, you can think of a variety of means that achieve it and discover one may be rather more likely for your situation, like if I was a Russian in Russia right now I'd have already made arrangements in case GH changes their mind or is legally forced to drop the ban hammer.) The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.) It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work). But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.
- philwelch 5y ago
  This has always been my #1 reservation about it. Seems like a weird degree of feature creep to me.
  - wyoung2 5y ago
    When Fossil didn't have those features, the frequent complaints were that Fossil doesn't have those features, and that's why they had to keep using $INERTIA_SOURCE. Now that it has those features, it's the reason not to move to it? I see. :) All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together. You can reference ticket IDs from a forum post. You can point to a section of the timeline from a wiki article. You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages. You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it. Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.
    - throwaway81523 5y ago
      Fossil is ideologically opposed to rebasing which makes it (according to its own docs iirc) not so good for large teams, since the repo is full of tons of useless little commits that git users squash out before merging.
    - philwelch 5y ago
      In my defense, I don’t ever recall a time that Fossil didn’t have all those features. Edit: I even have receipts. Me, 11 years ago: https://news.ycombinator.com/item?id=2524574 https://news.ycombinator.com/item?id=2524574 > 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.
simonw 5y ago
This is such an interesting piece of software. I recommend installing it to play around with it even if you have to intention at all of actually using it for real. You can import an existing Git repository into it really quickly. The app itself is built by the SQLite team, and takes full advantage of SQLite, in particular Many Small Queries Are Efficient In SQLite: https://www.sqlite.org/np1queryprob.html https://www.sqlite.org/np1queryprob.html
- mekster 5y ago
  This is pretty much do everything but don't do them well than isolated solutions. Every components seem like pretty limited in functionality. Why should one use that simple forum instead of Discourse? Why should one use the simple wiki than say Wiki.js? And of course the toolings are already way behind as in there's not a single GUI client? And it doesn't seem to have any social login, so people have to create an account instead of using GitHub logins. Who uses it outside SQLite team?
  - SubjectToChange 5y ago
    The SQLite project is much like SQLite itself, i.e. simple and as self contained as possible. Naturally this means they have to deal with the overhead of developing and maintaining a large portion of their toolchain. On the other hand they avoid the litany of problems that comes with using 3rd party tools, and those tools can be optimized for their particular needs. > Who uses it outside SQLite team? Tcl/Tk is the only big user of Fossil, as far as I'm aware.
pvg 5y ago
Some of the many previous threads: https://news.ycombinator.com/item?id=28168632 https://news.ycombinator.com/item?id=28168632 https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=26578581 https://news.ycombinator.com/item?id=26578581 https://news.ycombinator.com/item?id=24643200 https://news.ycombinator.com/item?id=24643200 https://news.ycombinator.com/item?id=21974942 https://news.ycombinator.com/item?id=21974942 https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=17230766 https://news.ycombinator.com/item?id=17230766 https://news.ycombinator.com/item?id=15752725 https://news.ycombinator.com/item?id=15752725 https://news.ycombinator.com/item?id=13668952 https://news.ycombinator.com/item?id=13668952 https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=10737131 https://news.ycombinator.com/item?id=10737131 https://news.ycombinator.com/item?id=8697028 https://news.ycombinator.com/item?id=8697028 https://news.ycombinator.com/item?id=3036124 https://news.ycombinator.com/item?id=3036124 https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=809493 https://news.ycombinator.com/item?id=809493
- passerby1 5y ago
  It would be good to see titles for links above. What's your point of listing them without titles?
  - tedunangst 5y ago
    It's a community effort. One person posts the links, then you come along and help out by posting the titles, then I help out by telling you what to do. Go team!
    - exdsq 5y ago
      Unacceptable Ted, do all the work
  - pvg 5y ago
    Like the other reply points out, it's fairly standard community practice to link previous discussions for those who might be interested in checking them out. dang (the public moderator) has automated up his postings of past links so they show titles and dates but that's work and I wasn't going to do it by hand for this chonklist. The good news is, eventually, the tectonic plate of HN development will reach 'make the fancier formatting automatic for everyone': https://news.ycombinator.com/item?id=27236708 https://news.ycombinator.com/item?id=27236708 The reply I really wanted to write was 'the point is to confuse passers by', though.
Multicomp 5y ago
I love the idea of fossil, git cli has horrible and unintuitive porcelain. There is no brain dead git undo (except for the 'well actually if you sell your soul to the reflog' folks), but ultimately, just like C and unix, git may be annoying in some ways but its inertia and ubiquity keep it going way longer than it's technical merits deserve when directly compared to competitors. Also, fossil feels like someone built it for almost NIH reasons, which I freely admit is just my outsiders impression, but it feels to me like the tcl community tends to dogfood themselves a lot for cultural reasons. But fossil is already more complete and battle tested than anything this lowly amateur will accomplish in his career.
- rndgermandude 5y ago
  As for NIH, kinda a bit but not really. Fossil was first released in 2006, Git in 2005 (mercurial in 2005 as well). At this point in time, there was no clear "DVCS" (distributed version control system) winner yet. The author of Fossil is drh, who is a lot more famous for being the author of sqlite (who also happens to be a major player in the TCL community). If I remember correctly[0], Fossil was written a) to dogfood sqlite (fossil uses sqlite) and also b) to get something able to not just do the VC part for sqlite, but tightly integrated issue tracking, docs, rel-eng, etc in one single system, as well as some VC-related features not present in git/mercurial and other competitors of the time (and in many cases not available in git or mercurial of today). [0] I looked into all this new-fangled DVCS stuff back then, because it looked really interesting compared to subversion that I was using at the time, and was a pain.
- SubjectToChange 5y ago
  > Also, fossil feels like someone built it for almost NIH reasons, Considering the rest of the SQLite development toolchain, it would be more surprising if they _didn't_ make something like fossil. Although shunning mainstream tools like git is probably rooted in a "not invented here" attitude, I love that they bother to do so. Of course it's interesting to see what bespoke solutions they come up with, but it's amazing to see such a highly complex piece of software come with such a trivial set of dependencies. Indeed, even if it's antisocial for the SQLite devs to play in their own sandbox, the end result is nothing but increased portability for the rest of us.
xeeeeeeeeeeenu 5y ago
The author of Fossil considers rebase harmful, and because of that, it wasn't implemented[1]. I'm not a fan of that decision. I don't want to live with my mistakes forever, especially on local branches. [1] - https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md
- thriftwy 5y ago
  Merges should be considered harmful and disabled by default. They ruin history, get in the way of bisect, may not be reproducible, etc, etc. Sometimes they may be used but more likely as a superuser operation
  - benatkin 5y ago
    GitHub's button to update the current branch annoys me. It creates a merge commit back from the main branch to the feature branch. I would rather it back up the current branch and rebase it or something, or just let me do it the right way manually (rebase and force push).
    - no_wizard 5y ago
      You can set on the repository if you want it to rebase instead[0] [0]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges https://docs.github.com/en/pull-requests/collaborating-with-...
      - benatkin 5y ago
        I know about that but don't know if it works for updating a branch before merging it. I'll have to try changing it to that setting.
      - tomn 5y ago
        Annoyingly this always re-writes commits (i.e. never fast-forwards), which means that if you have branches based on the branch you're merging they will need to be rebased, and git will complain about deleting the branch because it looks like it's unmerged.
999900000999 5y ago
I would love to see a better git compatible VCS. I'm not feeling good about self hosting my version control.
- arxanas 5y ago
  https://github.com/martinvonz/jj https://github.com/martinvonz/jj is a promising alternative which fixes many of the design mistakes of Git, but can still interact directly with Git repositories.
  - jchook 5y ago
    Funny that Google requires employees to say "THIS IS NOT A GOOGLE PROJECT, THIS IS MY 20% PROJECT", yet reserves the right to say "I can have this" at any point.
    - oh_sigh 5y ago
      Well, Google literally paid the salary of the developer while he was developing it. This isn't even like it was something done on his personal time that Google can stake ownership in since he works there. It literally is a work product, which just happens to be not supported by Google.
    - jamesmishra 5y ago
      The first one is a warranty issue. The second one is a work-for-hire-copyright-law issue.
  - 999900000999 5y ago
    Thanks this looks pretty cool. Honestly all I want is a git command that runs git commit . -m timestamp git push I probably do something like that every 20 minutes or so.
  - mekster 5y ago
    This is the right approach. Since everyone just stepped on to use git without thinking, "Because Linux uses it", we have to endure the pain of unfriendliness of git and it's already like S3 where if you want to start any competing project, it has to be git compatible to even get started. I suppose there are SubGit, hg-git, bzr-git trying to keep their respective version control while facing git on the other end. Somehow people miss these messages and projects like Bazaar got ran over by git for no good reason. > We take great pride in making Bazaar easy to learn, easy to use and suitable for everyone, not just elite hackers. > Ease of use is a core value for Bazaar and there are many places where our focus on usability shines though. http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html http://doc.bazaar.canonical.com/migration/en/why-switch-to-b... I thought people were looking for tools with this philosophy.
rubyist5eva 5y ago
My favourite thing about fossil is that the repo is a single SQLite database file so it’s extremely to just back it up or keep the repo in cloud storage. With Git I’ve always had problems with conflicts in the .git directory which messes things up, but fossil is a single file so it backs up to the cloud wonderfully.
- cakoose 5y ago
  That's surprising. Doesn't it seem like one big file would increase the odds of a sync conflict?
  - Skinney 5y ago
    for simgle users (hobby projects) that's not a concern. For teams, you'd go through a hosted server anyway.
    - cakoose 5y ago
      Sure, but the original post said that it was a concern for Git but not for Fossil. I was wondering why that is.
  - richie_adler 5y ago
    There is an extensively tested sync protocol, the whole file does not get synced each time. https://fossil-scm.org/home/doc/trunk/www/sync.wiki https://fossil-scm.org/home/doc/trunk/www/sync.wiki
    - cakoose 5y ago
      I think the original comment was talking about a generic sync utility, not about Fossil's or Git's own protocols: > so it’s extremely to just back it up or keep the repo in cloud storage A single big file seems like it would cause more issues for a generic sync utility. Though I guess I can imagine sync algorithms that work better with one style vs the other.
gregmac 5y ago
Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"? I don't like the monoculture either, but at this point some knowledge of git is an essential skill. In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else, hire/collaborate only with others who share the same view, and never interact with basically any other open source. So given some git knowledge is necessary anyway, there are alternatives interfaces to git that solve the simplicity problem, and any other tool is going to have friction (small ecosystem, few integrations, smaller community), why use something else? (I mean this genuinely) I just don't see the dominance of git changing for the next decade, especially if there's no answer to my first question (for whatever aims to replace it). It's not even like there's git lock-in: it could be replaced, just like SVN was. It's just it doesn't seem like there's compelling reason to, and thus no desire.
- bachmeier 5y ago
  One thing you can do with Fossil that you can't with Git is use the tickets database as a distributed, version controlled sqlite database, complete with user authentication, and trivially add extensions using CGI.
  - thunderbong 5y ago
    > trivially add extensions using CGI Can you elaborate on this please?
    - SQLite 5y ago
      Documentation here: https://fossil-scm.org/home/doc/trunk/www/serverext.wiki https://fossil-scm.org/home/doc/trunk/www/serverext.wiki
- josemando 5y ago
  I suggest taking a look at https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki I have never used, but I’m interested in trying… maybe some personal project in the future :)
oh_sigh 5y ago
Is fossil just a "me too" of git? The release date is suspiciously shortly after git.
- djur 5y ago
  It came out two years after Git and Mercurial. Richard Hipp cites Monotone (which preceded both) as an early influence, and says he evaluated Git, Mercurial, and Monotone before deciding to implement his own DVCS on top of SQLite in order to develop SQLite. https://fossil-scm.org/home/doc/trunk/www/history.md https://fossil-scm.org/home/doc/trunk/www/history.md
- qbasic_forever 5y ago
  It has explicitly different design goals than git. Read its comparison page of fossil vs. git features. Git is just a "me too" of the BitKeeper source control system that Linus used before he wrote git. Linus isn't even trying to hide the fact--he explicitly says he wrote git because he had to move off BitKeeper after a license conflict and he needed something that was functionally similar for kernel development.
keithalewis 5y ago
deleted 5y ago
[deleted]
farmin 5y ago
Github fills the gab between fossil and git and I don't need to host it myself.
pyjarrett 5y ago
I've been using Fossil as my own personal knowledge repository for a few months, and it's been wildly successful. It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. `fossil ui` hosting the server for my docs locally, and from my home server is super useful and easy. Some of the commands are super weird though, but I put them my homepage of my fossil docs :) The auto-sync feature helps since I work on multiple computers to help ensure that I don't get too far out of sync.
- olav 5y ago
  This is actually the use case I have in mind when I think of moving my personal knowledge management system knowfox to something more enduring like fossil. It currently is built on php/mysql with laravel with a web ui in bootstrap. This has become super annoying for a few years now because once a year or so I have to port it to a new version of laravel and cope with the new javascript framework du jour that it now promotes. This would be fine, of course, if you run an agency which extracts money from clients for continuous upgrades, but not for a personal project. Fossil, on the other hand, is built for longevity. It is a single executable and comes with all tools built in.
oofbey 5y ago
I remember when there were many different reasonable options for source control. I’ve really enjoyed recent years how there’s at least one thing in software development where basically everybody agrees what the right solution to a problem is. For source control, use git. Almost nobody disagrees. Is git perfect? Of course not. Is it hard to learn? Hell yeah. But everybody does, at least enough to get by. I find the standardization that git has brought to the industry to be wonderfully simplifying for the lives of people developing software. If only we could all agree on things like a programming language, or a database - how much more productive would we be? How many life years do we spend trying out or learning new technologies that don’t go anywhere, or which only offer marginal benefits in exchange for real sacrifices? At least for now, source control doesn’t have that level of constant churn which is so commonplace in software. To me, the benefits of standardization on git far outweighs any benefits that might be achieved by trying something new.
- kitd 5y ago
  Are you referring to "Git the standard format" or "Git the CLI" ? If the former, then yes I agree. If the latter, then definitely not, and I appreciate tools like Fossil & Mercurial that offer alternatives.
  - SQLite 5y ago
    Some issues with "Git the standard format": * Does not track cherry-picks * Does not track branch names * Tags must be unique. (You cannot add a "release" tag to every release, for example.) * Not easily extensible - witness the pain and years of effort trying to move from SHA1 to SHA2.
- anotherhue 5y ago
  I agree with you but I don't like that I do. Needles churn is one thing, but deliberately ceasing innovation and 'settling' seems like a loss. If we could all agree to a synchronised hype cycle that may help :)
- GordonS 5y ago
  I kind of agree. I don't like monoculture in general, but I'm not so adverse with git. I can remember where a place I worked used SVN, TFS, CVS and some commercial system (Perforce, I think), and it was really difficult switching between projects - I made quite a few mistakes. Git isn't perfect, but it's more than good enough.
danbmil99 5y ago
Does it have anything like lfs for large binary blobs?
jiriro 5y ago
Why that name “Fossil”? :-) I can imagine someone could feel reluctant to “Fossil” only because of the name. Also this reminds me about the Gimp – somehow not so catchy nomenclature.
- carterschonwald 5y ago
  Paleontology for code!
- zoomablemind 5y ago
  I could read it also as FOSSil with FOSS connotation (free and open-source software). Also, a single-file repos are akin to a historical artifacts of developers work and ideas surviving through the times. Don't we all have tons of projects sitting in their various state of abandon under the work directory? Well, Fossil lets us sweep the shame and organize these 'fossils' in a neat set of individual Fossil repo files in a grand /fossils or such directory. All repos 'readily' waiting to be respawned into a fresh work directory checkouts to perhaps offer some chance of completion. By the way, looks like the Fossil repos can be queried directly without a check-out into a separate directory. It simplifies the review of the history and contents.
lucasyvas 5y ago
It sounds to me that people are split on whether or not SCM should include things like issues and wikis directly, or let others solve it. Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in. Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git.
mfashby 5y ago
I'm curious how others do code review in fossil? It's something that GitHub is quite good at in my opinion; raising pull requests, having pre-merge checks, commenting on individual lines of changes, etc etc is all useful. It's something I can't see how to do in fossil.
cmacleod4 5y ago
Note that you can get free online fossil hosting at https://chiselapp.com/ https://chiselapp.com/ .
nagasadhu 5y ago
One thing that has prevented me from trying out fossil is there is no squash. The team has a principled stand on not having it.
nagasadhu 5y ago
I am not sold on the wiki and issue tracker. What would be a killer feature is a web UI interface to fossil commands like sublime merge for git.

207 points by cassepipe 5y ago

SuperSandro2000 5y ago

Do everything but everything mediocre.

umvi 5y ago

Seems like Fossil is more like an alternative to GitHub than Git. Fossil not only tracks code changes but team chat, bug tracking, wikis, etc.

leetrout 5y ago
Yes and no. It tracks the issues in the source repo. Everything is an artifact and some artifacts are bugs, technotes, etc https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki This is from the same person who made SQLite.
simonw 5y ago
That's the "batteries included" bit!
- pvg 5y ago
  That's something the submitter made up in the title, it's not how Fossil self-describes.
josephg 5y ago
Fossil is an alternative to both git (source control) and github (issues, etc). I think its brilliant having issues tracked in fossil. Part of the promise of github is that the user is in control, since your computer is a first-class citizen of a repository. You have all the code, and all the history on your computer. You can use github, but you don't need github, since its just another node in git's distributed network. But that promise falls apart with issues and pull requests. Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations. Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - You can have a project on both github and gitlab. And you can replicate commits to both. But you can't replicate issues using the same mechanism. Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant.
- benatkin 5y ago
  That's true. People imagine GitHub provides git, but that's the wrong way of seeing it. They do provide it on your server but the git running on your own computer is from the git project. GitHub does help significantly with the git project, though. Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/ https://git-scm.com/
- Jach 5y ago
  You're overstating the risks a bit and it's not great to posit implausible motives and means for bad outcomes... Like, Fossil devs could "turn evil", and ship an update that destroys your museum and any copies it can find. Github could "turn evil" without notice, and permanently nuke all of someone or some org's accounts for no good reason and yes, that'd catch a lot of people with their pants down. It's better to first focus on outcomes, not means. Of course anyone actually concerned about losing their github issue data (or having their museums corrupted) should at least be making backups. (And it's not exactly an implausible outcome on its own, you can think of a variety of means that achieve it and discover one may be rather more likely for your situation, like if I was a Russian in Russia right now I'd have already made arrangements in case GH changes their mind or is legally forced to drop the ban hammer.) The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.) It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work). But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.
philwelch 5y ago
This has always been my #1 reservation about it. Seems like a weird degree of feature creep to me.
- wyoung2 5y ago
  When Fossil didn't have those features, the frequent complaints were that Fossil doesn't have those features, and that's why they had to keep using $INERTIA_SOURCE. Now that it has those features, it's the reason not to move to it? I see. :) All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together. You can reference ticket IDs from a forum post. You can point to a section of the timeline from a wiki article. You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages. You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it. Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.
  - throwaway81523 5y ago
    Fossil is ideologically opposed to rebasing which makes it (according to its own docs iirc) not so good for large teams, since the repo is full of tons of useless little commits that git users squash out before merging.
  - philwelch 5y ago
    In my defense, I don’t ever recall a time that Fossil didn’t have all those features. Edit: I even have receipts. Me, 11 years ago: https://news.ycombinator.com/item?id=2524574 https://news.ycombinator.com/item?id=2524574 > 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.

simonw 5y ago

This is such an interesting piece of software. I recommend installing it to play around with it even if you have to intention at all of actually using it for real. You can import an existing Git repository into it really quickly. The app itself is built by the SQLite team, and takes full advantage of SQLite, in particular Many Small Queries Are Efficient In SQLite: https://www.sqlite.org/np1queryprob.html https://www.sqlite.org/np1queryprob.html

mekster 5y ago
This is pretty much do everything but don't do them well than isolated solutions. Every components seem like pretty limited in functionality. Why should one use that simple forum instead of Discourse? Why should one use the simple wiki than say Wiki.js? And of course the toolings are already way behind as in there's not a single GUI client? And it doesn't seem to have any social login, so people have to create an account instead of using GitHub logins. Who uses it outside SQLite team?
- SubjectToChange 5y ago
  The SQLite project is much like SQLite itself, i.e. simple and as self contained as possible. Naturally this means they have to deal with the overhead of developing and maintaining a large portion of their toolchain. On the other hand they avoid the litany of problems that comes with using 3rd party tools, and those tools can be optimized for their particular needs. > Who uses it outside SQLite team? Tcl/Tk is the only big user of Fossil, as far as I'm aware.

pvg 5y ago

Some of the many previous threads: https://news.ycombinator.com/item?id=28168632 https://news.ycombinator.com/item?id=28168632 https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=26578581 https://news.ycombinator.com/item?id=26578581 https://news.ycombinator.com/item?id=24643200 https://news.ycombinator.com/item?id=24643200 https://news.ycombinator.com/item?id=21974942 https://news.ycombinator.com/item?id=21974942 https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=17230766 https://news.ycombinator.com/item?id=17230766 https://news.ycombinator.com/item?id=15752725 https://news.ycombinator.com/item?id=15752725 https://news.ycombinator.com/item?id=13668952 https://news.ycombinator.com/item?id=13668952 https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=10737131 https://news.ycombinator.com/item?id=10737131 https://news.ycombinator.com/item?id=8697028 https://news.ycombinator.com/item?id=8697028 https://news.ycombinator.com/item?id=3036124 https://news.ycombinator.com/item?id=3036124 https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=809493 https://news.ycombinator.com/item?id=809493

passerby1 5y ago
It would be good to see titles for links above. What's your point of listing them without titles?
- tedunangst 5y ago
  It's a community effort. One person posts the links, then you come along and help out by posting the titles, then I help out by telling you what to do. Go team!
  - exdsq 5y ago
    Unacceptable Ted, do all the work
- pvg 5y ago
  Like the other reply points out, it's fairly standard community practice to link previous discussions for those who might be interested in checking them out. dang (the public moderator) has automated up his postings of past links so they show titles and dates but that's work and I wasn't going to do it by hand for this chonklist. The good news is, eventually, the tectonic plate of HN development will reach 'make the fancier formatting automatic for everyone': https://news.ycombinator.com/item?id=27236708 https://news.ycombinator.com/item?id=27236708 The reply I really wanted to write was 'the point is to confuse passers by', though.

Multicomp 5y ago

I love the idea of fossil, git cli has horrible and unintuitive porcelain. There is no brain dead git undo (except for the 'well actually if you sell your soul to the reflog' folks), but ultimately, just like C and unix, git may be annoying in some ways but its inertia and ubiquity keep it going way longer than it's technical merits deserve when directly compared to competitors. Also, fossil feels like someone built it for almost NIH reasons, which I freely admit is just my outsiders impression, but it feels to me like the tcl community tends to dogfood themselves a lot for cultural reasons. But fossil is already more complete and battle tested than anything this lowly amateur will accomplish in his career.

rndgermandude 5y ago
As for NIH, kinda a bit but not really. Fossil was first released in 2006, Git in 2005 (mercurial in 2005 as well). At this point in time, there was no clear "DVCS" (distributed version control system) winner yet. The author of Fossil is drh, who is a lot more famous for being the author of sqlite (who also happens to be a major player in the TCL community). If I remember correctly[0], Fossil was written a) to dogfood sqlite (fossil uses sqlite) and also b) to get something able to not just do the VC part for sqlite, but tightly integrated issue tracking, docs, rel-eng, etc in one single system, as well as some VC-related features not present in git/mercurial and other competitors of the time (and in many cases not available in git or mercurial of today). [0] I looked into all this new-fangled DVCS stuff back then, because it looked really interesting compared to subversion that I was using at the time, and was a pain.
SubjectToChange 5y ago
> Also, fossil feels like someone built it for almost NIH reasons, Considering the rest of the SQLite development toolchain, it would be more surprising if they _didn't_ make something like fossil. Although shunning mainstream tools like git is probably rooted in a "not invented here" attitude, I love that they bother to do so. Of course it's interesting to see what bespoke solutions they come up with, but it's amazing to see such a highly complex piece of software come with such a trivial set of dependencies. Indeed, even if it's antisocial for the SQLite devs to play in their own sandbox, the end result is nothing but increased portability for the rest of us.

xeeeeeeeeeeenu 5y ago

The author of Fossil considers rebase harmful, and because of that, it wasn't implemented[1]. I'm not a fan of that decision. I don't want to live with my mistakes forever, especially on local branches. [1] - https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

thriftwy 5y ago
Merges should be considered harmful and disabled by default. They ruin history, get in the way of bisect, may not be reproducible, etc, etc. Sometimes they may be used but more likely as a superuser operation
- benatkin 5y ago
  GitHub's button to update the current branch annoys me. It creates a merge commit back from the main branch to the feature branch. I would rather it back up the current branch and rebase it or something, or just let me do it the right way manually (rebase and force push).
  - no_wizard 5y ago
    You can set on the repository if you want it to rebase instead[0] [0]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges https://docs.github.com/en/pull-requests/collaborating-with-...
    - benatkin 5y ago
      I know about that but don't know if it works for updating a branch before merging it. I'll have to try changing it to that setting.
    - tomn 5y ago
      Annoyingly this always re-writes commits (i.e. never fast-forwards), which means that if you have branches based on the branch you're merging they will need to be rebased, and git will complain about deleting the branch because it looks like it's unmerged.

999900000999 5y ago

I would love to see a better git compatible VCS. I'm not feeling good about self hosting my version control.

arxanas 5y ago
https://github.com/martinvonz/jj https://github.com/martinvonz/jj is a promising alternative which fixes many of the design mistakes of Git, but can still interact directly with Git repositories.
- jchook 5y ago
  Funny that Google requires employees to say "THIS IS NOT A GOOGLE PROJECT, THIS IS MY 20% PROJECT", yet reserves the right to say "I can have this" at any point.
  - oh_sigh 5y ago
    Well, Google literally paid the salary of the developer while he was developing it. This isn't even like it was something done on his personal time that Google can stake ownership in since he works there. It literally is a work product, which just happens to be not supported by Google.
  - jamesmishra 5y ago
    The first one is a warranty issue. The second one is a work-for-hire-copyright-law issue.
- 999900000999 5y ago
  Thanks this looks pretty cool. Honestly all I want is a git command that runs git commit . -m timestamp git push I probably do something like that every 20 minutes or so.
- mekster 5y ago
  This is the right approach. Since everyone just stepped on to use git without thinking, "Because Linux uses it", we have to endure the pain of unfriendliness of git and it's already like S3 where if you want to start any competing project, it has to be git compatible to even get started. I suppose there are SubGit, hg-git, bzr-git trying to keep their respective version control while facing git on the other end. Somehow people miss these messages and projects like Bazaar got ran over by git for no good reason. > We take great pride in making Bazaar easy to learn, easy to use and suitable for everyone, not just elite hackers. > Ease of use is a core value for Bazaar and there are many places where our focus on usability shines though. http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html http://doc.bazaar.canonical.com/migration/en/why-switch-to-b... I thought people were looking for tools with this philosophy.

rubyist5eva 5y ago

My favourite thing about fossil is that the repo is a single SQLite database file so it’s extremely to just back it up or keep the repo in cloud storage. With Git I’ve always had problems with conflicts in the .git directory which messes things up, but fossil is a single file so it backs up to the cloud wonderfully.

cakoose 5y ago
That's surprising. Doesn't it seem like one big file would increase the odds of a sync conflict?
- Skinney 5y ago
  for simgle users (hobby projects) that's not a concern. For teams, you'd go through a hosted server anyway.
  - cakoose 5y ago
    Sure, but the original post said that it was a concern for Git but not for Fossil. I was wondering why that is.
- richie_adler 5y ago
  There is an extensively tested sync protocol, the whole file does not get synced each time. https://fossil-scm.org/home/doc/trunk/www/sync.wiki https://fossil-scm.org/home/doc/trunk/www/sync.wiki
  - cakoose 5y ago
    I think the original comment was talking about a generic sync utility, not about Fossil's or Git's own protocols: > so it’s extremely to just back it up or keep the repo in cloud storage A single big file seems like it would cause more issues for a generic sync utility. Though I guess I can imagine sync algorithms that work better with one style vs the other.

gregmac 5y ago

Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"? I don't like the monoculture either, but at this point some knowledge of git is an essential skill. In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else, hire/collaborate only with others who share the same view, and never interact with basically any other open source. So given some git knowledge is necessary anyway, there are alternatives interfaces to git that solve the simplicity problem, and any other tool is going to have friction (small ecosystem, few integrations, smaller community), why use something else? (I mean this genuinely) I just don't see the dominance of git changing for the next decade, especially if there's no answer to my first question (for whatever aims to replace it). It's not even like there's git lock-in: it could be replaced, just like SVN was. It's just it doesn't seem like there's compelling reason to, and thus no desire.

bachmeier 5y ago
One thing you can do with Fossil that you can't with Git is use the tickets database as a distributed, version controlled sqlite database, complete with user authentication, and trivially add extensions using CGI.
- thunderbong 5y ago
  > trivially add extensions using CGI Can you elaborate on this please?
  - SQLite 5y ago
    Documentation here: https://fossil-scm.org/home/doc/trunk/www/serverext.wiki https://fossil-scm.org/home/doc/trunk/www/serverext.wiki
josemando 5y ago
I suggest taking a look at https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki I have never used, but I’m interested in trying… maybe some personal project in the future :)

oh_sigh 5y ago

Is fossil just a "me too" of git? The release date is suspiciously shortly after git.

djur 5y ago
It came out two years after Git and Mercurial. Richard Hipp cites Monotone (which preceded both) as an early influence, and says he evaluated Git, Mercurial, and Monotone before deciding to implement his own DVCS on top of SQLite in order to develop SQLite. https://fossil-scm.org/home/doc/trunk/www/history.md https://fossil-scm.org/home/doc/trunk/www/history.md
qbasic_forever 5y ago
It has explicitly different design goals than git. Read its comparison page of fossil vs. git features. Git is just a "me too" of the BitKeeper source control system that Linus used before he wrote git. Linus isn't even trying to hide the fact--he explicitly says he wrote git because he had to move off BitKeeper after a license conflict and he needed something that was functionally similar for kernel development.

keithalewis 5y ago

deleted 5y ago

[deleted]

farmin 5y ago

Github fills the gab between fossil and git and I don't need to host it myself.

pyjarrett 5y ago

I've been using Fossil as my own personal knowledge repository for a few months, and it's been wildly successful. It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. `fossil ui` hosting the server for my docs locally, and from my home server is super useful and easy. Some of the commands are super weird though, but I put them my homepage of my fossil docs :) The auto-sync feature helps since I work on multiple computers to help ensure that I don't get too far out of sync.

olav 5y ago
This is actually the use case I have in mind when I think of moving my personal knowledge management system knowfox to something more enduring like fossil. It currently is built on php/mysql with laravel with a web ui in bootstrap. This has become super annoying for a few years now because once a year or so I have to port it to a new version of laravel and cope with the new javascript framework du jour that it now promotes. This would be fine, of course, if you run an agency which extracts money from clients for continuous upgrades, but not for a personal project. Fossil, on the other hand, is built for longevity. It is a single executable and comes with all tools built in.

oofbey 5y ago

I remember when there were many different reasonable options for source control. I’ve really enjoyed recent years how there’s at least one thing in software development where basically everybody agrees what the right solution to a problem is. For source control, use git. Almost nobody disagrees. Is git perfect? Of course not. Is it hard to learn? Hell yeah. But everybody does, at least enough to get by. I find the standardization that git has brought to the industry to be wonderfully simplifying for the lives of people developing software. If only we could all agree on things like a programming language, or a database - how much more productive would we be? How many life years do we spend trying out or learning new technologies that don’t go anywhere, or which only offer marginal benefits in exchange for real sacrifices? At least for now, source control doesn’t have that level of constant churn which is so commonplace in software. To me, the benefits of standardization on git far outweighs any benefits that might be achieved by trying something new.

kitd 5y ago
Are you referring to "Git the standard format" or "Git the CLI" ? If the former, then yes I agree. If the latter, then definitely not, and I appreciate tools like Fossil & Mercurial that offer alternatives.
- SQLite 5y ago
  Some issues with "Git the standard format": * Does not track cherry-picks * Does not track branch names * Tags must be unique. (You cannot add a "release" tag to every release, for example.) * Not easily extensible - witness the pain and years of effort trying to move from SHA1 to SHA2.
anotherhue 5y ago
I agree with you but I don't like that I do. Needles churn is one thing, but deliberately ceasing innovation and 'settling' seems like a loss. If we could all agree to a synchronised hype cycle that may help :)
GordonS 5y ago
I kind of agree. I don't like monoculture in general, but I'm not so adverse with git. I can remember where a place I worked used SVN, TFS, CVS and some commercial system (Perforce, I think), and it was really difficult switching between projects - I made quite a few mistakes. Git isn't perfect, but it's more than good enough.

danbmil99 5y ago

Does it have anything like lfs for large binary blobs?

jiriro 5y ago

Why that name “Fossil”? :-) I can imagine someone could feel reluctant to “Fossil” only because of the name. Also this reminds me about the Gimp – somehow not so catchy nomenclature.

carterschonwald 5y ago
Paleontology for code!
zoomablemind 5y ago
I could read it also as FOSSil with FOSS connotation (free and open-source software). Also, a single-file repos are akin to a historical artifacts of developers work and ideas surviving through the times. Don't we all have tons of projects sitting in their various state of abandon under the work directory? Well, Fossil lets us sweep the shame and organize these 'fossils' in a neat set of individual Fossil repo files in a grand /fossils or such directory. All repos 'readily' waiting to be respawned into a fresh work directory checkouts to perhaps offer some chance of completion. By the way, looks like the Fossil repos can be queried directly without a check-out into a separate directory. It simplifies the review of the history and contents.

lucasyvas 5y ago

It sounds to me that people are split on whether or not SCM should include things like issues and wikis directly, or let others solve it. Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in. Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git.

mfashby 5y ago

I'm curious how others do code review in fossil? It's something that GitHub is quite good at in my opinion; raising pull requests, having pre-merge checks, commenting on individual lines of changes, etc etc is all useful. It's something I can't see how to do in fossil.

cmacleod4 5y ago

Note that you can get free online fossil hosting at https://chiselapp.com/ https://chiselapp.com/ .

nagasadhu 5y ago

One thing that has prevented me from trying out fossil is there is no squash. The team has a principled stand on not having it.

nagasadhu 5y ago

I am not sold on the wiki and issue tracker. What would be a killer feature is a web UI interface to fossil commands like sublime merge for git.