Fossil is like a git+Gitea-all-in-one self-contained-executable and I run it to manage my personal notes at home. It’s pretty wild in that it stores tickets, wiki, user management and such in the repository which is just an SQLite database. This makes backup super easy.
If you want an example of what the interface looks like, see Pikchr.
It’s easy to self-host at home and you can run the webserver from your repo locally to update tickets, wiki, markdown docs, and so on and then sync back. It “just works” – but handles syncing a bit differently than git. I don’t need to push when committing, it syncs back automatically if I’m on my network. There’s a bit more to it than this, and it suffers from the same DVCS issues for making games as git such as dealing poorly with large binaries – I know about git-lfs, but Perforce really is as close to gold standard as you can get.
I might be doing more with Fossil since scraping of GitHub for AI training makes me not want to post code publicly anymore, and it gives me better control if I wanted contributors, to self-host on Linode or something.
Thank you for mentioning these features. I’m easily nerd sniped, but I’ve gotten better at not running after the nearest shiny thing. git works well enough for me (and we use a type of hg at work) and my experience is that I adapt to whatever other people use, and just use it. I think most widely used versioning systems work for most cases about the same.
Most of those feature bullet points also apply to git, or most other DVCSs. Of the ones that don’t: it doesn’t matter to me how easy it is to install, or how many binaries, because git is already installed. And I have a lovely Git GUI client (Fork).
I imagine there are concrete pluses to Fossil, but this article didn’t list any (that are relevant to me.)
Agreed. While I certainly don’t think git is the last word in version control, it’s so good that it’s probably only going to be surpassed by something that is completely surprising to most of us. I’m expecting it will be as different from git as git was from cvs (I’m not forgetting svn, I just think the difference will have to be that much bigger).
It is! Fossil was made for projects with a small number of contributors that trust each other, where drive-by contributions are rare and changes are shared often and openly (more info on that here).
For me, that’s the model for the vast majority of the repositories I contribute to.
I tried using Fossil for my personal projects but discovered that the the following two Git features have become essential for my workflow: (1) partial file commits and (2) rewriting commit history. Fossil doesn’t have (1) and is specifically designed to disallow (2). As much as I liked the built-in bug tracker and wiki, I couldn’t use Fossil and went back to Git.
We have Fossil repos at work and aside from the fact Fossil intergrates with almost nothing, these two things are huge pain points, especially lack of history rewrites.
Most repos have been moved away from Fossil at this point.
For (1), Fossil docs recommend stashing the changes and splitting them into patches:
fossil stash save -m 'my big ball-o-hackage'
fossil stash diff > my-changes.patch
For each git add -p you’d call git stash diff instead. I agree it’s a bit less convenient, an interactive version would be nice.
For (2), what’s your use-case? For me Fossil removes a lot of cases for which I would use history rewriting in Git. Note that Fossil also has amend, which changes history non-destructively - you can peek the previous state. As for lack of rebases, there’s a good write-up here.
I do want to use fossil for my current project (I believe it also has an auto-backup functionality to mirror your changes to a git repo hosted somewhere) but am worried that it takes the probability of someone else contributing from 1% to 0.1%. It isn’t even git per se, a lot of people only know how to file a github-style PR at this point. I suppose the only way this changes is by project maintainers en masse shouldering the burden of educating users on alternatives.
More optimistically, contributions by other people can eventually be too much of a good thing so maybe alternative PR workflows will filter out the ones you don’t want to deal with.
Indeed, I’ve never had a Fossil contribution by someone I didn’t manually walk through the process. Even then, I’ve never had a repeat contribution after that.
I still use it for personal stuff, stuff that I’m never going to want to get contributions from anyway. I love it, I even build websites with it.
But for a project that will want contributors, it’s definitely a hard sell.
The FSF process is public and composed of a pair of emails (though possibly a pair of emails per package you want to contribute to). The FSF doesn’t mind you contributing.
SQLite does not document their process at all (it used to but that was removed in February 2018) what they say is:
All code authors, and representatives of the companies they work for, have signed affidavits dedicating their contributions to the public domain and originals of those signed affidavits are stored in a fire safe at the main office of Hwaci. All contributors are citizens of countries that allow creative works to be dedicated to the public domain.
The SQLite project indicates to this day that they do not accept patches, you’re free to include such in a bug report, but they are unlikely to care for it.
This seems to have been removed, but older versions of the copyright page further indicated that sqlite had had only 27 individual contributors, only 16 still had extant code in the tree, and just two had authored more than 96% of the code at the time (February 2018).
The sqlite project does not want external contributions.
More importantly, potential contributors need to create an account on it. GitHub’s big advantage is the network effects: most potential contributors already have an account.
Technically true. But you can view the full UI locally with fossil ui, which starts a server and launches a browser. So as long as you have ssh access to any server to dump the repo file on, you have a working remote repo. And if you’re developing entirely alone you get the entire UI without any dedicated server at all.
If your specific goal is to publish code to the public using Fossil, yeah you would have to set up a server. Personally I just mirror my Fossil repos to GitHub if I care about sharing them.
The post states the problem well enough, but it’s unclear why Fossil is the solution.
Fossil is like a git+Gitea-all-in-one self-contained-executable and I run it to manage my personal notes at home. It’s pretty wild in that it stores tickets, wiki, user management and such in the repository which is just an SQLite database. This makes backup super easy.
If you want an example of what the interface looks like, see Pikchr.
It’s easy to self-host at home and you can run the webserver from your repo locally to update tickets, wiki, markdown docs, and so on and then sync back. It “just works” – but handles syncing a bit differently than git. I don’t need to push when committing, it syncs back automatically if I’m on my network. There’s a bit more to it than this, and it suffers from the same DVCS issues for making games as git such as dealing poorly with large binaries – I know about git-lfs, but Perforce really is as close to gold standard as you can get.
I might be doing more with Fossil since scraping of GitHub for AI training makes me not want to post code publicly anymore, and it gives me better control if I wanted contributors, to self-host on Linode or something.
I think it’s worth adding that the entire binary is 4 megabytes.
Thank you for mentioning these features. I’m easily nerd sniped, but I’ve gotten better at not running after the nearest shiny thing.
gitworks well enough for me (and we use a type ofhgat work) and my experience is that I adapt to whatever other people use, and just use it. I think most widely used versioning systems work for most cases about the same.Most of those feature bullet points also apply to git, or most other DVCSs. Of the ones that don’t: it doesn’t matter to me how easy it is to install, or how many binaries, because git is already installed. And I have a lovely Git GUI client (Fork).
I imagine there are concrete pluses to Fossil, but this article didn’t list any (that are relevant to me.)
Agreed. While I certainly don’t think git is the last word in version control, it’s so good that it’s probably only going to be surpassed by something that is completely surprising to most of us. I’m expecting it will be as different from git as git was from cvs (I’m not forgetting svn, I just think the difference will have to be that much bigger).
Software use is a social phenomenon, not a technical one.
It is! Fossil was made for projects with a small number of contributors that trust each other, where drive-by contributions are rare and changes are shared often and openly (more info on that here).
For me, that’s the model for the vast majority of the repositories I contribute to.
I tried using Fossil for my personal projects but discovered that the the following two Git features have become essential for my workflow: (1) partial file commits and (2) rewriting commit history. Fossil doesn’t have (1) and is specifically designed to disallow (2). As much as I liked the built-in bug tracker and wiki, I couldn’t use Fossil and went back to Git.
We have Fossil repos at work and aside from the fact Fossil intergrates with almost nothing, these two things are huge pain points, especially lack of history rewrites.
Most repos have been moved away from Fossil at this point.
For (1), Fossil docs recommend stashing the changes and splitting them into patches:
For each
git add -pyou’d callgit stash diffinstead. I agree it’s a bit less convenient, an interactive version would be nice.For (2), what’s your use-case? For me Fossil removes a lot of cases for which I would use history rewriting in Git. Note that Fossil also has amend, which changes history non-destructively - you can peek the previous state. As for lack of rebases, there’s a good write-up here.
EDIT: you can also delete content when really needed.
I do want to use fossil for my current project (I believe it also has an auto-backup functionality to mirror your changes to a git repo hosted somewhere) but am worried that it takes the probability of someone else contributing from 1% to 0.1%. It isn’t even git per se, a lot of people only know how to file a github-style PR at this point. I suppose the only way this changes is by project maintainers en masse shouldering the burden of educating users on alternatives.
More optimistically, contributions by other people can eventually be too much of a good thing so maybe alternative PR workflows will filter out the ones you don’t want to deal with.
Indeed, I’ve never had a Fossil contribution by someone I didn’t manually walk through the process. Even then, I’ve never had a repeat contribution after that.
I still use it for personal stuff, stuff that I’m never going to want to get contributions from anyway. I love it, I even build websites with it.
But for a project that will want contributors, it’s definitely a hard sell.
It’s one of the design choice due to 99% of the sqlite user won’t contribute to it, and it’s a very tiny circle of developers
The average sqlite user can not contribute to it, sqlite literally self documents as “open source not open contribution”.
You need to submit an affidavit and do a bunch of paperwork before there’s any chance they’ll look at patches.
Like the FSF?
Significantly more of it from my understanding.
The FSF process is public and composed of a pair of emails (though possibly a pair of emails per package you want to contribute to). The FSF doesn’t mind you contributing.
SQLite does not document their process at all (it used to but that was removed in February 2018) what they say is:
The SQLite project indicates to this day that they do not accept patches, you’re free to include such in a bug report, but they are unlikely to care for it.
This seems to have been removed, but older versions of the copyright page further indicated that sqlite had had only 27 individual contributors, only 16 still had extant code in the tree, and just two had authored more than 96% of the code at the time (February 2018).
The sqlite project does not want external contributions.
Me like it
The main fossil problem is that there’s not a GitHub out there for people that don’t want to set up a CGI server.
There’s https://chiselapp.com/
The
fossil serversubcommand supports serving HTTP directly.I still have to set up a server though
More importantly, potential contributors need to create an account on it. GitHub’s big advantage is the network effects: most potential contributors already have an account.
Maybe fossil can figure out federation before forgefed?
Technically true. But you can view the full UI locally with
fossil ui, which starts a server and launches a browser. So as long as you have ssh access to any server to dump the repo file on, you have a working remote repo. And if you’re developing entirely alone you get the entire UI without any dedicated server at all.If your specific goal is to publish code to the public using Fossil, yeah you would have to set up a server. Personally I just mirror my Fossil repos to GitHub if I care about sharing them.
I was expecting a user experience, this is a list of selling points.
The only thing keeping me from using Fossil for all my projects right now is my tooling.
I can probably run
s/git/fossil/gon the Lazygit repo and some (neo)vim plugins and it might all just work.