From Git to Fossil (2025)
27 points by heavyrain266
27 points by heavyrain266
People at Git has started to work on a proposal to make the Rust1 programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip.
Right, those people are the weird ones...
Distaste for the author aside, Fossil is very close to what I want out of a "forge."
What's lacking for me is a code-review system and a better CI story. I get the sense that Fossil is great for personal repos or projects with a small number of trusted committers (given the lack of branch protections for those with merge capabilities). Also, the timestamp-based branch tip stuff just feels like it's asking for trouble.
I think my grail VCS/forge would be:
The tone is a little much, but I do feel like Rust evangelists are particularly enthusiastic, and Rust seems to find itself in projects that I wouldn't expect to need it.
Meh:
There's a certain kind of person that's going to evangelize NewShiny no matter what it is (Nix, Rust, Zig...ok I'm just listing projects that I actually like at this point lol).
and Rust seems to find itself in projects that I wouldn't expect to need it.
I am one of these Rust evangelists, but sorry, why should Rust be a language of last resort? I don't think the Rust evangelism is out of sync with the underlying merits (obviously so — if I thought otherwise I wouldn't be one).
I didn't say it is, Rust is a great first choice for a lot of things.
I've seen quite a few projects shoehorn Rust into their build process because of some vague advantage (usually "performance" or "memory safety") when it doesn't really seem necessary from my perspective.
And why shouldn't they? If you want to make your software run in 5 seconds where it used to take 10, go have fun in Rust. Git, being a C app, will probably eventually maybe see performance and memory safety benefits from using Rust in new components / rewriting old components in it.
I just think that's sometimes done because Rust is in vogue rather than because there's an appreciable benefit.
related: Software Drives People Insane
when it doesn't really seem necessary from my perspective.
Right. I just think this is overall a good thing.
I do feel sorry for people who get the brunt force of some very loud voices that want to push $newtech into things.
But the git authors I think are not part of that group, so the only relevant objection is that they dislikes the language. Which must be a very strong feeling for switching away from the resulting software. Heck I don't like Go all that much, but I do love syncthing - and that's totally fine.
What exactly is the point of this comment? I comes off as mean for the sake of being mean. People on this site refuse to use tools for all kinds of different reasons, including which language it is written in. This hardly seems very unusual (even if I wouldn't do such anymore)
I could copy and paste your comment about the bit that I quoted. It seems needlessly harsh, and a bit off the wall.
It strikes me as very ironic for the author to have this slightly unhinged take on people he calls "extremists", "totalitarian", and "delusion[al]". They also say that they produce "crap". Let's also set aside that the author hasn't actually identified anyone doing this, which makes this a bit of a straw man.
If you can't see how this is worthy of ridicule, I can't help you.
(Bias disclosure: I like Rust but am not an evangelist.)
If you can't see how this is worthy of ridicule, I can't help you.
I, for one, don't think any disagreement is improved by ridicule.
(I recognize that this view might be unfashionable, and that it might be partly caused by an undiagnosed case of virtue ethics, which also might be unfashionable.)
(I do think what you quoted is harsher than your own reaction to it.)
Personally I read it as implying (though not directly stating) an objection to the so-called wokeness in the Rust community. That's even though there's plenty of unwoke things about Rust — weapons manufacturers use Rust, for instance.
they use user names so if you have a public repository you don't have to be worried about spam and you don't need a specific email address for this use only.
I'm not sure if those helps anyone, but just in case: the email doesn't matter. Just use a random string if you want. You can still sign your commits.
Fossil is one of my favorite programs, period. I self host all my codebases using fossil and even use it partially in production at work.
How do you handle code review and/or CI?
We don’t really use it for its intended purpose at work — we are using it as a poor man’s code deployment/config management tool in a highly locked-down environment where a single binary that needs no permissions and could transfer over https.
I have used fossil in a different production context where it was used for our main VC. In this context it was fine to just put your contributions in a separate branch and someone could check out that branch to do review as they saw fit. It was a small enough team that this worked out fine.
If CI is a serious concern the recommendation is to export to Git. It’s easy to have a synchronized git mirror of your Fossil repo and that serves as a compatibility layer. In principle, nothing stops Fossil from being usable with CI tools someone would just need to do the work to translate it.
It’s also possible to have your CI tool subscribe to Fossil’s built-in RSS feed and use that to know when to run a build.
In this context it was fine to just put your contributions in a separate branch and someone could check out that branch to do review as they saw fit. It was a small enough team that this worked out fine.
This tracks with my perception that it works best as a forge for a relatively small group of trusted maintainers.
I've seen the git/RSS advice, strikes me as a bit hacky 😅 I want my green checkmark dopamine hit
I just looked up Fossil and learned that it's written by the D. Richard Hipp, the primary author of SQLite. I must try Fossil!
Well, it's written for SQLite pretty much. If you have a development team of three people that have been working on something together for almost 30 years with scarce outside contribution, it is proven for that use case.
What a horrible start to an intro to fossil... It's awesome and i especially love it's single-file hosting ability for a directory of them but woof does that first paragraph make me hope I never come across this blog again.