I would like to introduce you lovely OpenSource Lovers to a GIT-Alternative called FOSSIL that I also stumbled upon.<br> 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
& It’s also <u>self-hostable</u> & the best part it’s all in ONE STANDALONE FILE!!! 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”<br> The person behind Fossil is the creator of SQLite, <u>Dr.Richard Hipp</u> & they even made other projects to support Fossil like a PIC-Like language called PikChr
Well here’s a difference between Git vs Fossil & they even have a hosting service called CHISEL
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.