I would like to introduce you lovely OpenSource Lovers to a GIT-Alternative called FOSSIL that I also stumbled upon because of this Blog. It's basically opensource Github-in-a-box which means it's an SCM with:
- Bug-tracker
- Ticketting-system
- Forum
- Wiki-system
- even a Chat-functionality
- Has built-in GUI
- Also has a Web-Server
- Self-Hostable like Gitea/Forgejo
& the best part it's all in ONE STANDALONE FILE!!! which is extremely lightweight which you can copy to your $PATH & works even in crappy internet. how cool is that!!
However this tool supports a completely different style of development in FOSS called the "Cathedral-Style" whereas GIT suports a "Bazaar-Style" The person behind Fossil is the creator of SQLite, Dr.Richard Hipp & they even made other projects to support Fossil like a PIC-Like language called PikChr Well just in case; here's a list of difference between Git vs Fossil & guess what!! they even have a hosting service called CHISEL
Listen; Just check it out & use it for fun in your spare time even with the flaws it has (& Try out Darcs & Pijul as well)
I really like the idea of using a relation db to track change history. It removes so much weirdness and quirkiness that git has. You just have regular SQL queries you can use to go through history and ask questions about the state of the repo. I also like that it's immutable so you don't have to worry about things like rebasing and other ways you can fuck up history in git. The problems solved by mucking with history largely go away when you can query the db with a rich syntax.
Same, really love the idea of backing history with a proper database, and the immutability. git rebasing was a mistake.
Rebasing is for advanced git users who knows what he's doing. If one does not know how to use it or not feeling comfortable in general, he can happily take his own code and try to merge it into the latest version instead. No one is judging.
For the rest of the world where projects are open-source, more often than not, not those projects inside a corporation where only the team lead is making decisions, it's a powerful tool to settle down conflicts sort out history.
One does not need to change the history again, if he's not comfortable with it. Just use git as if it's centralised VCS like SVN. No big deal. In fact, in corporations you do. There only needs to be one person who manages the repository.
I get why it exists, but yeah it's more trouble than it's worth in most cases.
How do you cleanly base your local changes against a new upstream version? Merges?
You merge from them. If you're working on a PR, they can always squash merge your commits if you have a lot of them. No history rewriting required.