Hacker News Reader

> Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"?

If you click on the link it lists a ton of additions to git. The first bullet lists "bug tracking, wiki, forum, email alerts, chat, and technotes" none of which are supported by git.

Then again, bullet 4 is "Self-host Friendly" (every git client is also a full git server -- after all it's fully distributed) and bullet 5 is "Simple Networking - Fossil uses ordinary HTTPS (or SSH if you prefer)" Pretty sure git supports https out of the box these days (though I don't use it -- ssh is so much simpler).

So yes, I would call those killer features for those who want them, and are pretty unique to any revision control system I've used, though some centralized sites have encrusted git with those features. Having them distributed sounds like a good idea.

> Then again, bullet 4 is "Self-host Friendly" (every git client is also a full git server -- after all it's fully distributed)

Sure, for code. But fossil distributes issues and wiki the same way, which makes comprehensive self hosting much easier.

I suppose. Personally I don’t like this level of tool integration (I don’t like IDEs either); I prefer the pick and choose / best of breed / Unix approach.

what self-hosted, offline available, system do you use for bug tracking, wiki and forums?

I’m not sure the “extra batteries included” line is very persuasive.

It’s open to objections: first, Github does this already, so it’s a solved problem. Second, lack of focus. Why would VCS experts be good at designing a compelling forum or ticketing system?

A more compelling selling point, which is buried in the docs, is the use of SQLite as storage. Apparently this makes it easy to traverse a commit’s descendants, which git struggles with.

> It’s open to objections: first, Github does this already, so it’s a solved problem.

I can buy the reasoning that it's a solved problem with additional software, but citing github specifically here is absurd.

Github is a SaaS, centralised, closed source and unfederated platform.

I can understand that you think they're a good service, but there's a huge difference between something like git (which is a tool and a flexible one) and SVN, vs a hosted service.

You can think of it like VLC media player vs youtube.

Sure. If you think everything centralized, closed source and federated should be replaced with something decentralized, federated and open source, then Github is unacceptable. Just note that these are not inherently features. They may at some point become useful features - if e.g. all closed source software eventually is exploited by monopolists - but that is a very particular viewpoint. Given the success of Github, it seems that many people don't yet share that view. So, if I were persuading people to use Fossil, I would try to focus on features that most people want. But OK, if it's going for a free software niche, then fine.

> It’s open to objections: first, Github does this already, so it’s a solved problem

No, you're misunderstanding the feature (or they don't explain it well). GitHub solves the problem on their platform yes, but not in the protocol (git) itself.

Fossil embeds that data in the repository, all the data is local. Fossil works perfectly with the "local first" doctrine, something Git also does, but not for everything around Git, that Fossil embeds into the repository.

Basically, Fossil is Git + GitHub but self-hosted and offline first. You pull down a Fossil repository is like pulling down the Git repository + all related GitHub data.

> Why would VCS experts be good at designing a compelling forum or ticketing system?

They don't have to be experts about something to make it good enough. For a lot of us with poor internet connectivity, the offline first doctrine is essential in a lot of the work we do, as internet can disappear at any notice. Fossil works much better for this, as I can still read the wiki and tickets when my internet drops, while if I were using GitHub, I'd have to results to writing my own code/use 3rd party software to get the same experience.

I don't find these arguments persuasive. My point was that if I want wiki, ticketing etc., I can get it right now on an industry standard platform. Yes, I get that they embed it in the software itself. So what? Suppose someone said "our new operating system includes a web browser". But I already have a web browser? "Yes, but we embed it in the kernel itself!" Why would that be compelling?

The other argument, that this is needed for offline use, is more meaningful. I don't personally think this is a big enough deal to be the USP. But sure, for some people it may be.

Bullet 2, “Built-in Web Interface”, is also not quite something that makes Fossil stand out as opposed to Git, because most installations of Git come with gitweb[1]. It's not the pinnacle of modern web-design, sure, but if you just want to browse a repo through a web interface, it's perfectly fine.

[1]: https://git-scm.com/docs/gitweb

Yeah, in the case of Git, the web ui is very simple, as Git only cares about code. In the case of Fossil, the web ui is extensive, as Fossil stores all types of data, not just code.

As an interesting example, the very website in this submission (fossil-scm.org) is in fact just a standalone Fossil website, running as you'd run your own repository. Everything that is on that website, is something you get for free for each repository you use Fossil for.

> The first bullet lists "bug tracking, wiki, forum, email alerts, chat, and technotes" none of which are supported by git.

Oh, so systemd of SCM world?

Also, making moving out of it extra hard by embracing everything.

Fossil imports and exports git

https://fossil-scm.org/home/doc/tip/www/inout.wiki

Fossil is more self-host friendly if you're on a shared hosting plan, since it works via CGI and can be served via nginx/Apache with minimal configuration. Every git hosting solution I'm aware of requires a dedicated daemon.

I like it for projects which may need to live a really long time between changes. Having a single .fossil file containing the entire project, it's history, documentation, and tickets in a set location makes it simple to pick something back up after x years. The optional web UI is simple HTML that is unlikely to break in future browsers. Finally, fossil is typically distribed as a single static binary, which makes it easy to install/update.

If I was to have to build a VCS from source decades from now to get to my repo, I believe that fossil will be much simpler than git (which has a fair amount of build dependencies).

Other commenters are talking about GitHub/Discord/Jira etc but I think that's missing the point a bit - in 20 years time are those closed sass services still going to exist? If they are, is your project still going to be there? And will you remember which flavour of the month sass you used for tickets?

> Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"?

Fossil is basically GitHub itself stuffed inside the DVCS. Issues and the wiki are stored alongside the code.

While there are a few differences in operating principles, probably 90% of the baseline knowledge required to use Git is the same as with Fossil (and Mercurial for that matter). If you already know Git, you can learn Fossil in less than 30 minutes, and IME there is very little context switching cost if using multiple VCSs.

In that sense, I don't believe Git has a knowledge lock in, because it is easy for anyone to switch or to simultaneously use available alternatives. It's all about the ecosystem, and really, Github.

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.

> trivially add extensions using CGI

Can you elaborate on this please?

Documentation here: https://fossil-scm.org/home/doc/trunk/www/serverext.wiki

I suggest taking a look at 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 :)

The big ticket item is obviously that Fossil includes all the stuff that people constantly whine about being locked into Git{hub,lab} over, e.g. issues, as part of the tool rather than some external vendor-specific thing you have to worry about separately.

Also, as someone who really liked Monotone before git won, having your whole repo in a single file is just nice for the same ops-related reasons it’s refreshing to be able to download and run a self-contained binary rather than needing an installer or whatever.

A killer-feature measure is not very useful way of selection, as it's not how projects select a VCS - many projects/teams have individual requirements which affect such feature considerations.

In my somewhat simplified view, Git's 'killer-feature' by now is simply its ubiquity.

By the same token, for Fossil's this could be claimed as a single binary that does it all.

Just download the binary, and you've got the ubiquitous set of project-related facilities: VCS/tickets/docs/wiki/team/forum/chat with simple aporoach to sync and self-host.

> 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

I worked with a guy once who took a principled stand against git and (almost) exclusively interacted with the org's git repos through Hg-Git: https://hg-git.github.io/

Did he ever explain to what his issue with git was and why he took a stand against it?

I helped him resolve a really gnarly octopus merge through git once and we had a nice chat about it.

A. He liked Mercurial more, although I forget all his reasonings. Mercurial's commands are definitely better named, no contest.

B. He hated that git was "winning" and so tried to help prolong Mercurial's lifespan by writing plugins and helping out in the ecosystem.

If you are a professional developer git is an essential skill, and will be for the foreseeable future.

But that doesn’t make git or fossil right for every project.

Fortunately you can easily switch between them.

See https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

It’s fantastic for personal projects. The ticket system is highly customisable, I usually set it up a bit like a todo list. It’s super easy to self host.

(Yes I obviously still use Git as well)

I also use the Fossil issue system as a todo list. Feels "more real" than listing things in a spreadsheet.

> In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else

This is a strange thing to say. It's like saying the only chance you have of avoiding python is to use something else.

> never interact with basically any other open source.

You don't need git knowledge to download an open source library from GitHub (there's tarballs on the web page), or to use your languages package manager, even if it speaks git under the hood (go get/npm)

> I just don't see the dominance of git changing for the next decade,

The dominance of git is real particularly in certain industries, but even now git still has terrible support for huge repositories and binary files, partial checkouts, submodules. The problem is that most projects are suited just fine to the limitations of git, (and SVN and p4 and hg), so the value comes in the supporting tooling and infrastructure. Why would I choose fossil over git when for free I can get everything that GitHub/gitlab provides for me?

All the bug tracking and wikis being integrated is amazing.

Sadly, it's not git and nobody else is using it, and I'm not a fan of using lots of nonstandard tech.

It seems to be better than Git, but there's no free hosts that are as big as Github/Gitlab, and convincing other people to switch technology is very hard.

Plus, the people obsessed with clean commit history won't like the lack of easy squash and rebase.

Mercurial was. A good contender for a while. I still think immutable history has some advantages.

Mercurial’s tracking of the evolution of patch sets was really useful. GitHub PR’s mostly achieve that even if it’s lost at the native git level.

why "was"? mercurial is still around, and perfectly usable. we use it at work and I've never had any problems with it, it's pretty much as good as git for day to day usage.

There's pretty much nowhere to host your repo now that bitbucket gave up (and outright /deleted/ all hg repos which was criminal, but that's besides the point)

The big three I know of (github, gitlab, bitbucket) are all git-only.

Totally true for the "big three", but Sourcehut hosts mercurial repositories: https://hg.sr.ht/.

(Unaffiliated, but a happy user.)

I'm glad there are some hold outs. It's a great technology it's just not been adopted as much as git. I had to learn git as most job ads specified git.

Honestly, I think the killer feature of Git was GitHub, and it was made popular by people wanting to use GitHub. The rest of the features were cherries on top of being able to use GitHub.

So I guess the killer feature for Fossil would be Fossil in that case, as Fossil is basically Git + GitHub but in one package, that works offline and local first.