Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used it in earnest a number of times. Their immutability stance is at the root of the problems. Lack of rebase is most infamous, but you can't even edit a ticket description! Make a typo or error in the description, and you're expected to append more notes, or delete and recreate the ticket.
I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.
I think it's less about immutability and more about visibility.
The argument made by the Fossil project, AFAIU, is that it has a better log view than git and has better traceability through SQL based search in addition t the cli and web interface.
To me, associating a wiki page to a commit makes way more sense than as a commit message that's part of the commit. This way the message can give a summary and then the detail is given in full-fledged markup file that has its own version history.
Totally fair if that's not something that works for you, though.
Every time fossil comes up, I hear this same issue - "why is there no rebase?"
And honestly, I've never been able to get this argument. It's a version management system! It's supposed to maintain the history of what's been done, both good and bad. In fact, that's the whole point of a VCS, isn't it?
IMHO, if we want to show a different path than what's been actually taken for the codebase to reach where it is now, we might as well use a network drive to store the different versions. Why bother with a VCS then?
I use both, and I prefer fossil. But my coworkers hate fossil because they can't fake their commits to make them look good. This is something I actually like about fossil: git has tools just to make things look pretty even if they can cause serious headaches (rebase), so users are skewed towards good looking timelines made with dirty commits then rearranged and squashed. OTOH fossil forces you to do your best but accept that sometimes you botch it, and have to mark a commit as "does not build".
And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened".
There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy.
From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed".
What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?
Here a developer thought that redis would be a good add to the stack, so we decided he should try. It turned out that it didn't fit, mainly because it needed to touch code in more places than anticipated. We went back to starting point, but the project now carries a "no more redis/cache attempts before reading this one, please" fossil. New attempts can't say "oh, I didn't know this was attempted before".
With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records.
This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).
This sounds more like some elitism. Who cares how your coworkers got there, the point is to have good history at the origin. People don't need to see your dirty laundy, there is nothing interesting about it.
> People don't need to see your dirty laundy, there is nothing interesting about it.
We disagree here, thus we prefer different tools. Nothing elitist here.
I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
In the most common git setups, you never force-push to master - so a coworker can't rewrite history of master branch. Forges have protection rules, but even if your hosting does not, then the "git pull" will throw a ton of errors after history rewrites. So both fossil and git are similar in that regards.
On the other hand, unpushed branches can be rewritten any time in git.. but this applies to fossil as well. If you have not pushed your fossil changes, it's just a file on disk - you can delete it without pushing and no one will ever know you had intermediate version. Or work in "git" and only export to fossil (or svn or cvs or whatever) once things work.
Secrets that is committed anyway has to be assumed as compromised. So those secrets must be immediately changed. Removing it from history would help a bit, but is not a reliable mitigation.
This was CVS/SVN approach, and that's the reason git won so quickly (no, it was not github like some people claimed, I've seen git become popular in my circle before github was a thing)
I am not sure if you used CSV/SVN before - I did. It maintained the history of what was done in a very immutable way. The branches were heavy-weight and were only used for Serious Business, we generally had a person responsible for branching/merging. You only committed stuff which was in great shape and passed all the tests, just like Fossil wants you now.
And there were manual source code copying, so much copying.
- You are writing a feature and got interrupted mid-work to work on something else - copy/tar those files and restore from svn (you could also do a second checkout, but that destroys your cache).
- Want to send incomplete changes to friend? run "diff" and send them the patch by email, or place that patch file on shared disk.
- Your check-in failed, you need to merge in in latest changes from master? better tar up your work in case you break stuff.
- Are you doing new feature and want to see if refactor will improve it? don't forget to make a copy of changed files in case it does not.
None of this is worth committing on master. Who would want to share an incomplete feature which does not build / does not pass unit tests? Or an pre-refactor version of code which does not work?
Turns out using "git" covers all those usecases, and that's why it's the greatest thing. Fun fact: we've started using git in our team using git-svn, without central git server - we had mutable and shareable commits until the last moment, when we pushed it to central svn server.
IMHO, if you only want to record the final path code takes, and you plan to use "cp", "tar" and "patch" for throw-away work, then you might as well use a "releases" directory on FTP with timestamped archives. Why bother with VCS then?
History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
And this highlights my frustration. I don’t want to have this debate. The tool should allow its operator to set whatever level of strictness or purity they want for their project. Fossil already offers a million settings. Add another and make me turn on “dangerously-unsafe-rebase” to get the feature if need be.
What you're wanting is against their philosophy. However, there is removal via shunning. There's also the query langauge to control the view. So, there's everything you need to do what you want.
Obviously that's going to take some figuring out for queries and aliases. But it seems doable to me.
Awkward, yes, but doable. AFAICT, they've provided a way to do things that go against their philosophy should anyone be inclined.
Suppose a secret like some personally identifying information was recently leaked into the main branch. You are legally required to scrub it. How do you fix it?
Ideally a repo needs to reflect the state of every event that happened. Practically there are edge cases when it's just best to rewrite history.
IMHO the best and most relevant part of fossil these days is the ticket system, which is in every single way almost completely ideal for coding agents. Some features are: single-binary, in-repo, CLI or web UI, and offline / sql / markdown-friendly.
Since the whole tracker is just a thin front on sqlite with the above features there's many options. Use it per-project persistently so as to include co-workers, or only locally for your own agents to "think" inside of so they are less likely to dump CoT all over the code-comments. Use it even at a per task granularity, and throw it away afterwards. Do all three, fossil doesn't care! And the agents will love it.
> IMHO the best and most relevant part of fossil these days is the ticket system, which is in every single way almost completely ideal for coding agents.
Funnily enough, that's collectively fossil's developers' least-favorite part. We make no secret about not liking the ticket system, and we only use it when we need to record a certain ticket for posterity's sake. Aside from that, we use the forum for all ticket-like traffic.
> Since the whole tracker is just a thin front on sqlite ...
Though I just vented in another comment about fossil, I'll admit that all of my experience was in the pre-agentic era. Since an agent won't be as easily annoyed (heck, it happily belts out sqlite's tedious schema alternation dance without pause), I'm curious to try pointing it fossil as the scm for a project.
I honestly think the article misinterpreted the Git mailing list email.
The first line of the article says:
"People at Git has started to work on a proposal to make the Rust programming language mandatory."
This sounded to me like all future code would need to be Rust.
But the Git mailing list email says:
"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure."
Also, the original Git mailing list email says:
"[author is porting to Rust the...] "varint.c" subsystem, mostly because it is trivial and does not have any dependencies."
So, the email on the Git list says they are testing changing a small piece
of C code to Rust, and Rust build tools will be mandatory [to build] (which is not surprising if a non-optional part of the code base is Rust).
> If you are among the unfortunate ones who have their master branch named as "main" this option is not for you and you should check Fossil's documentation if you want to rename it.
This is by far the most perplexing part of this article for me:
> People at Git has started to work on a proposal to make the Rust 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.
I've been programming for a longish time, and I've acquired my own set of opinions about programming languages, but I can't think of any that I dislike so strongly that I would need to boycott projects that use them under the hood. Moreover, even if we accept the "community of little extremist characters" claim for the sake of argument, is that at all relevant to the Git situation? I haven't seen any evidence that introducing Rust into the code base is the result of extremism, rather than just a mundane technology choice. Finally, when Rust is made "mandatory," it does not mean you must use Rust now, it just means that Rust is required to build the source code. The vast majority of people wouldn't even know that Rust was used. Even most Git developers wouldn't need to use Rust, since after more than a year from the original proposal, the Git source tree is still almost entirely written in C and shell scripts, and the amount of Rust code is basically a rounding error.
The whole Rust issue seems like a big nothingburger, and this reaction seems completely irrational to me.
rust solves a real problem. It makes it much harder to create a large class of bugs, bugs that are in most C and C++ projects (and many other languages). Sure, maybe rusteans have bad attitudes. Not sure that's true but I do get the annoyance of "I re-wrote cat in rust!".
We see these C/C++ bugs all over. Mozilla just fixed a ton of them, most of which would not have existed if Firefox was written in rust (see servo). That doesn't mean there would be zero bugs. It means there would be less. But by some accounts, a ton less, especially of the security issue kind.
And it's not just about the op, the op being a perfect expert programmer who never writes bugs. It's about someone quits, someone who doesn't know the code as well and takes over, they quit, someone who knows the code even less takes over, and in that world, the person adding a new feature to the app/tool/library is far less likely to add a security bug to a rust repo than an C/C++ repo.
> rewriting projects that have been working for decades
They have been working for decades AND are full of security bugs!
Switching them to rust generally means (1) the existing security bugs are gone (2) most future updates are far less likely to add new ones.
Note: I'm not a rust programmer. I'm a C++ programmer dealing with the fact that there are so many UaF bugs in our code with > 1000 programmers. We know more will be added because C++ does not prevent them and we're not perfect. Rust does, or at least it prevents enough of them to be worth it.
The friction is not an issue of the language or of toxic communities but the culture of how software is crafted and passed on. I use rust for hobby projects and besides the savety and soundness decisions, i love the tooling. Having countless [0] very restrictive guard rails like deny(clippy::float_arithmetic) for your usecases codifies intent about project structure in a way i have seen nowhere else. Not engaging with the benefits of rust but instead blanket-dismiss projects based on unrelated issues is irrational and i suspect its a phenomenon of older generations that grew up with C and never inherited eg. cobol on mainframes.
Your arguments make sense but I also understand how the OP may have such allergic reaction. I also have seen my share of young devs claiming this new thing is the best thing since sliced bread and that everyone shoud use it. This may be a new language or a new feature like objects. After many slices of bread you may develop an allergy to such fanatics, and react with an opposing force to their eagerness to conquer the world.
Allergy is a poor analogy here, since it develops by not exposing yourself. I can understand your annoyance, i got bitten by hypes aswell, including rust. I am not regretting it so far.
I believe there have been a number of crusades started around people's behavior and usually get a code of conduct book thrown at them. I remember a notable Python dev who had this happen to him, over sharing some humor from an old SNL skit related to a poorly chosen acronym for some tech, an otherwise extremely helpful and resourceful person got hammered and drumed out of the community. The rust community may have that same tone policing vibe. I enjoy and appreciate the value of using rust, and nix, both have this vibe at times and I make sure I "don't cross the streams" it sure has a stifling effect.
I'm sympathetic to hostility towards many members of the Rust development community, many of whom are left-progressives who think it's politically and morally important to exclude and socially-punish people who they view as being insufficiently deferential towards communities they deem marginalized.
But Rust is actually a better language than C, in multiple ways; and it is in fact bad that so much software in common use is still written in C. C is extremely hard to write correctly and hard to maintain; this fact explains a huge amount of security vulnerabilities in the widely-used software written in C. Rust mitigates this to a large extent, and is also just more pleasant to write because it has better syntactic and semantic affordances than C does - also better developer tooling.
I think that people who are not Anglophone left-progressives should use Rust, in part because I think it is bad that a highly useful programming language is associated with Anglophone left-progressives. Certainly, regardless of one's non-programming-related political beliefs, you should not ground your identity in making a virtue out of sticking to C.
I agree that the rust community tends to be pretty toxic, but I don't think that is a good reason to avoid tools just because they use rust under the hood. You don't have to participate in the git dev community, let alone the rust community, to use git as your VCS.
I think one thing about git needing rust (or python or Perl) is that each language dependency adds another good sized chunk of storage for the language and its tools/packager, I have a relatively light project using Tauri Svelte and code mirror, my build directory/cache becomes 18gb in the blink of an eye, that's a whole bloated modern operating system as a side effect of building a text editor, I should just wrap webkit-GTK around a redbean with some js libs in a directory, script the middleware in Lua and call it a day :D And don't get me wrong I like the development workflow with Tauri, it feels very performant, and easy to reason with, just the sheer disk space makes me boggle!
.. and even then there are other solutions like "GoT" - https://gameoftrees.org/ - which is interoperable with Git but written in that lovely OpenBSD C.
I love Fossil and I use it for my projects. I understand why it isn't for everyone, but considering I am the sole developer on the stuff I make (and I agree with Dr. Hipp about the drawbacks of rebase), it's perfect for my needs. Lightweight, has its own integrated web server and forge features should I need them, and it's dead easy to use. It isn't the one VCS to rule them all (no such thing exists, really), but I do encourage people to check it out because they might fall in love like I did.
What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Fossil has no way to fix it, by design, and I find it an absolute showstopper. I do stupid mistakes all the time, and I am so glad that gits lets me fix those.
"Fossil purposely makes it difficult for users to delete content."
Those operations are explicitly declared special, not something you do many times per day because you had a typo in your print statement. I guess technically you can do it often, but the tooling does not make it easy at all, and you are going against program's recommended best practices.
> What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Then you have proven that you are human.
> Fossil has no way to fix it, by design,
As an 18-year-long contributor to fossil i can assure you that this is absolutely not true. Fossil can amend any checkin and it can move checkins to other branches. Go to sqlite.org/src/timeline?r=mistake to see many examples of where human failing has been both demonstrated and accounted for without breaking anything.
14 "mistakes" in the entire 2025. I am probably making that many per week? Not to mention committing the intentionally broken stuff, with the expectation that I'll come back and amend if I decided it should go to main.
Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used it in earnest a number of times. Their immutability stance is at the root of the problems. Lack of rebase is most infamous, but you can't even edit a ticket description! Make a typo or error in the description, and you're expected to append more notes, or delete and recreate the ticket.
I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.
I think it's less about immutability and more about visibility.
The argument made by the Fossil project, AFAIU, is that it has a better log view than git and has better traceability through SQL based search in addition t the cli and web interface.
What kind of note are you using? There are several and, if I recall correctly, that affects the view a bit. See the "Auxiliary notes attached to check-ins or branches" https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki
To me, associating a wiki page to a commit makes way more sense than as a commit message that's part of the commit. This way the message can give a summary and then the detail is given in full-fledged markup file that has its own version history.
Totally fair if that's not something that works for you, though.
Every time fossil comes up, I hear this same issue - "why is there no rebase?"
And honestly, I've never been able to get this argument. It's a version management system! It's supposed to maintain the history of what's been done, both good and bad. In fact, that's the whole point of a VCS, isn't it?
IMHO, if we want to show a different path than what's been actually taken for the codebase to reach where it is now, we might as well use a network drive to store the different versions. Why bother with a VCS then?
How about temporary commits locally, that then get squashed to ensure each build cleanly? Or secrets that shouldn’t have been committed?
Maybe it what an ironical question ^^
This is what private branches do
https://fossil-scm.org/home/doc/trunk/www/private.wiki
I use both, and I prefer fossil. But my coworkers hate fossil because they can't fake their commits to make them look good. This is something I actually like about fossil: git has tools just to make things look pretty even if they can cause serious headaches (rebase), so users are skewed towards good looking timelines made with dirty commits then rearranged and squashed. OTOH fossil forces you to do your best but accept that sometimes you botch it, and have to mark a commit as "does not build".
And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened".
There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy.
From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed".
What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
> but this has significant disadvantages and practically no advantages (other than "accuracy of what happened".
...which is a very big advantage, big enough that it outweighs the disadvantages in my opinion.
Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?
Here a developer thought that redis would be a good add to the stack, so we decided he should try. It turned out that it didn't fit, mainly because it needed to touch code in more places than anticipated. We went back to starting point, but the project now carries a "no more redis/cache attempts before reading this one, please" fossil. New attempts can't say "oh, I didn't know this was attempted before".
With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records.
This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).
This sounds more like some elitism. Who cares how your coworkers got there, the point is to have good history at the origin. People don't need to see your dirty laundy, there is nothing interesting about it.
> People don't need to see your dirty laundy, there is nothing interesting about it.
We disagree here, thus we prefer different tools. Nothing elitist here.
I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
Agreed.
In teams, only the history of what is committed to shared repo is important.
There is something wrong with this explanation.
In the most common git setups, you never force-push to master - so a coworker can't rewrite history of master branch. Forges have protection rules, but even if your hosting does not, then the "git pull" will throw a ton of errors after history rewrites. So both fossil and git are similar in that regards.
On the other hand, unpushed branches can be rewritten any time in git.. but this applies to fossil as well. If you have not pushed your fossil changes, it's just a file on disk - you can delete it without pushing and no one will ever know you had intermediate version. Or work in "git" and only export to fossil (or svn or cvs or whatever) once things work.
Secrets that is committed anyway has to be assumed as compromised. So those secrets must be immediately changed. Removing it from history would help a bit, but is not a reliable mitigation.
Your definition of version control isn’t the same as mine, probably. Why even ask this? People have preferences and different beliefs.
This was CVS/SVN approach, and that's the reason git won so quickly (no, it was not github like some people claimed, I've seen git become popular in my circle before github was a thing)
I am not sure if you used CSV/SVN before - I did. It maintained the history of what was done in a very immutable way. The branches were heavy-weight and were only used for Serious Business, we generally had a person responsible for branching/merging. You only committed stuff which was in great shape and passed all the tests, just like Fossil wants you now.
And there were manual source code copying, so much copying.
- You are writing a feature and got interrupted mid-work to work on something else - copy/tar those files and restore from svn (you could also do a second checkout, but that destroys your cache).
- Want to send incomplete changes to friend? run "diff" and send them the patch by email, or place that patch file on shared disk.
- Your check-in failed, you need to merge in in latest changes from master? better tar up your work in case you break stuff.
- Are you doing new feature and want to see if refactor will improve it? don't forget to make a copy of changed files in case it does not.
None of this is worth committing on master. Who would want to share an incomplete feature which does not build / does not pass unit tests? Or an pre-refactor version of code which does not work?
Turns out using "git" covers all those usecases, and that's why it's the greatest thing. Fun fact: we've started using git in our team using git-svn, without central git server - we had mutable and shareable commits until the last moment, when we pushed it to central svn server.
IMHO, if you only want to record the final path code takes, and you plan to use "cp", "tar" and "patch" for throw-away work, then you might as well use a "releases" directory on FTP with timestamped archives. Why bother with VCS then?
Can none of this be addressed using "probate branches"?
https://fossil-scm.org/home/doc/trunk/www/private.wiki
History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
And this highlights my frustration. I don’t want to have this debate. The tool should allow its operator to set whatever level of strictness or purity they want for their project. Fossil already offers a million settings. Add another and make me turn on “dangerously-unsafe-rebase” to get the feature if need be.
What you're wanting is against their philosophy. However, there is removal via shunning. There's also the query langauge to control the view. So, there's everything you need to do what you want.
Obviously that's going to take some figuring out for queries and aliases. But it seems doable to me.
Awkward, yes, but doable. AFAICT, they've provided a way to do things that go against their philosophy should anyone be inclined.
Suppose a secret like some personally identifying information was recently leaked into the main branch. You are legally required to scrub it. How do you fix it?
Ideally a repo needs to reflect the state of every event that happened. Practically there are edge cases when it's just best to rewrite history.
IMHO the best and most relevant part of fossil these days is the ticket system, which is in every single way almost completely ideal for coding agents. Some features are: single-binary, in-repo, CLI or web UI, and offline / sql / markdown-friendly.
Since the whole tracker is just a thin front on sqlite with the above features there's many options. Use it per-project persistently so as to include co-workers, or only locally for your own agents to "think" inside of so they are less likely to dump CoT all over the code-comments. Use it even at a per task granularity, and throw it away afterwards. Do all three, fossil doesn't care! And the agents will love it.
> IMHO the best and most relevant part of fossil these days is the ticket system, which is in every single way almost completely ideal for coding agents.
Funnily enough, that's collectively fossil's developers' least-favorite part. We make no secret about not liking the ticket system, and we only use it when we need to record a certain ticket for posterity's sake. Aside from that, we use the forum for all ticket-like traffic.
> Since the whole tracker is just a thin front on sqlite ...
Except that it's not: <https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...>
Sounds interesting, can you give an example on how you (or your) agents work with fossil. How do (you make) the agents "think" inside (the repo)?
[dead]
Though I just vented in another comment about fossil, I'll admit that all of my experience was in the pre-agentic era. Since an agent won't be as easily annoyed (heck, it happily belts out sqlite's tedious schema alternation dance without pause), I'm curious to try pointing it fossil as the scm for a project.
I honestly think the article misinterpreted the Git mailing list email.
The first line of the article says:
"People at Git has started to work on a proposal to make the Rust programming language mandatory."
This sounded to me like all future code would need to be Rust.
But the Git mailing list email says:
"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure."
Also, the original Git mailing list email says:
"[author is porting to Rust the...] "varint.c" subsystem, mostly because it is trivial and does not have any dependencies."
So, the email on the Git list says they are testing changing a small piece of C code to Rust, and Rust build tools will be mandatory [to build] (which is not surprising if a non-optional part of the code base is Rust).
> If you are among the unfortunate ones who have their master branch named as "main" this option is not for you and you should check Fossil's documentation if you want to rename it.
oh great, another weirdo
(2025).
This is by far the most perplexing part of this article for me:
> People at Git has started to work on a proposal to make the Rust 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.
I've been programming for a longish time, and I've acquired my own set of opinions about programming languages, but I can't think of any that I dislike so strongly that I would need to boycott projects that use them under the hood. Moreover, even if we accept the "community of little extremist characters" claim for the sake of argument, is that at all relevant to the Git situation? I haven't seen any evidence that introducing Rust into the code base is the result of extremism, rather than just a mundane technology choice. Finally, when Rust is made "mandatory," it does not mean you must use Rust now, it just means that Rust is required to build the source code. The vast majority of people wouldn't even know that Rust was used. Even most Git developers wouldn't need to use Rust, since after more than a year from the original proposal, the Git source tree is still almost entirely written in C and shell scripts, and the amount of Rust code is basically a rounding error.
The whole Rust issue seems like a big nothingburger, and this reaction seems completely irrational to me.
I agree with you.
rust solves a real problem. It makes it much harder to create a large class of bugs, bugs that are in most C and C++ projects (and many other languages). Sure, maybe rusteans have bad attitudes. Not sure that's true but I do get the annoyance of "I re-wrote cat in rust!".
We see these C/C++ bugs all over. Mozilla just fixed a ton of them, most of which would not have existed if Firefox was written in rust (see servo). That doesn't mean there would be zero bugs. It means there would be less. But by some accounts, a ton less, especially of the security issue kind.
And it's not just about the op, the op being a perfect expert programmer who never writes bugs. It's about someone quits, someone who doesn't know the code as well and takes over, they quit, someone who knows the code even less takes over, and in that world, the person adding a new feature to the app/tool/library is far less likely to add a security bug to a rust repo than an C/C++ repo.
> rewriting projects that have been working for decades
They have been working for decades AND are full of security bugs!
Switching them to rust generally means (1) the existing security bugs are gone (2) most future updates are far less likely to add new ones.
Note: I'm not a rust programmer. I'm a C++ programmer dealing with the fact that there are so many UaF bugs in our code with > 1000 programmers. We know more will be added because C++ does not prevent them and we're not perfect. Rust does, or at least it prevents enough of them to be worth it.
I agree.
The friction is not an issue of the language or of toxic communities but the culture of how software is crafted and passed on. I use rust for hobby projects and besides the savety and soundness decisions, i love the tooling. Having countless [0] very restrictive guard rails like deny(clippy::float_arithmetic) for your usecases codifies intent about project structure in a way i have seen nowhere else. Not engaging with the benefits of rust but instead blanket-dismiss projects based on unrelated issues is irrational and i suspect its a phenomenon of older generations that grew up with C and never inherited eg. cobol on mainframes.
https://github.com/rust-lang/rust-clippy
Your arguments make sense but I also understand how the OP may have such allergic reaction. I also have seen my share of young devs claiming this new thing is the best thing since sliced bread and that everyone shoud use it. This may be a new language or a new feature like objects. After many slices of bread you may develop an allergy to such fanatics, and react with an opposing force to their eagerness to conquer the world.
Allergy is a poor analogy here, since it develops by not exposing yourself. I can understand your annoyance, i got bitten by hypes aswell, including rust. I am not regretting it so far.
I believe there have been a number of crusades started around people's behavior and usually get a code of conduct book thrown at them. I remember a notable Python dev who had this happen to him, over sharing some humor from an old SNL skit related to a poorly chosen acronym for some tech, an otherwise extremely helpful and resourceful person got hammered and drumed out of the community. The rust community may have that same tone policing vibe. I enjoy and appreciate the value of using rust, and nix, both have this vibe at times and I make sure I "don't cross the streams" it sure has a stifling effect.
I'm sympathetic to hostility towards many members of the Rust development community, many of whom are left-progressives who think it's politically and morally important to exclude and socially-punish people who they view as being insufficiently deferential towards communities they deem marginalized.
But Rust is actually a better language than C, in multiple ways; and it is in fact bad that so much software in common use is still written in C. C is extremely hard to write correctly and hard to maintain; this fact explains a huge amount of security vulnerabilities in the widely-used software written in C. Rust mitigates this to a large extent, and is also just more pleasant to write because it has better syntactic and semantic affordances than C does - also better developer tooling.
I think that people who are not Anglophone left-progressives should use Rust, in part because I think it is bad that a highly useful programming language is associated with Anglophone left-progressives. Certainly, regardless of one's non-programming-related political beliefs, you should not ground your identity in making a virtue out of sticking to C.
When is a culture war even rational?
the rust community is trash tho. such bad personalities all around. "mirrors" the issues with the nix community tbh..
I agree that the rust community tends to be pretty toxic, but I don't think that is a good reason to avoid tools just because they use rust under the hood. You don't have to participate in the git dev community, let alone the rust community, to use git as your VCS.
I think one thing about git needing rust (or python or Perl) is that each language dependency adds another good sized chunk of storage for the language and its tools/packager, I have a relatively light project using Tauri Svelte and code mirror, my build directory/cache becomes 18gb in the blink of an eye, that's a whole bloated modern operating system as a side effect of building a text editor, I should just wrap webkit-GTK around a redbean with some js libs in a directory, script the middleware in Lua and call it a day :D And don't get me wrong I like the development workflow with Tauri, it feels very performant, and easy to reason with, just the sheer disk space makes me boggle!
.. and even then there are other solutions like "GoT" - https://gameoftrees.org/ - which is interoperable with Git but written in that lovely OpenBSD C.
Yeah I stopped reading at that point. Can't trust the reasoning anywhere else in an article once you run into that kind of stuff.
Update - current Fossil versions no longer store user passwords unencrypted as shown in the "Setting up" section of this article.
If all you want is a simple read-only web presence for a Git repository, there are plenty of solutions. Here's mine:
https://repo.autonoma.ca/repo/treetrek
I looked at fossil a long time ago and liked it a lot, but settled on git as it's more "standard". I guess I will have to take a look at fossil again.
Off-topic, but I kinda like the style sheet of this article.
I love Fossil and I use it for my projects. I understand why it isn't for everyone, but considering I am the sole developer on the stuff I make (and I agree with Dr. Hipp about the drawbacks of rebase), it's perfect for my needs. Lightweight, has its own integrated web server and forge features should I need them, and it's dead easy to use. It isn't the one VCS to rule them all (no such thing exists, really), but I do encourage people to check it out because they might fall in love like I did.
What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Fossil has no way to fix it, by design, and I find it an absolute showstopper. I do stupid mistakes all the time, and I am so glad that gits lets me fix those.
It does: https://fossil-scm.org/home/doc/tip/www/shunning.wiki.
"Fossil purposely makes it difficult for users to delete content."
Those operations are explicitly declared special, not something you do many times per day because you had a typo in your print statement. I guess technically you can do it often, but the tooling does not make it easy at all, and you are going against program's recommended best practices.
> What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Then you have proven that you are human.
> Fossil has no way to fix it, by design,
As an 18-year-long contributor to fossil i can assure you that this is absolutely not true. Fossil can amend any checkin and it can move checkins to other branches. Go to sqlite.org/src/timeline?r=mistake to see many examples of where human failing has been both demonstrated and accounted for without breaking anything.
14 "mistakes" in the entire 2025. I am probably making that many per week? Not to mention committing the intentionally broken stuff, with the expectation that I'll come back and amend if I decided it should go to main.
Who cares. Add another commit is the answer.
Did you try pijul (https://pijul.org/) ?
Stopped reading after a few sentences of the first paragraph.
[dead]