alt Hacker NewsIt's kind of late, though, right? Git had core components ("plumbing") in C from 2005, with gradual rewriting of the "porcelain" layer from Perl to C in the late 2000s and early 2010s. People have been complaining about Mercurial performance for a long time. I'm sure the Python 2->3 headache did not help.
Replies
andrewshadura • yesterday at 9:47 PM
There was no headache. The migration was extremely smooth.
➕ show 1 reply
While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on):
- Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily
- `commit` just commits all indexed files with changes, no need for staging
- Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil).
- `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient.
- `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here.
All in all switching to Fossil after a ton of time using git has been a great experience overall.