[tomesch1982]

That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into.

I mainly use fossil for personal projects.

Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously easy and everyone always has everything in the repository.

In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

And fossil has a sane command-line interface so that everyone in the team is expert enough to work with it. No need for heroes that save the day from git fricking everything up.

[LaGrange]

> Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management.

That is not nice. That is way more things that might not match me, more attack surface, more irrelevant cruft I'll probably have to look up how to disable. Project management, wiki and issue tracking preferences are very personal and often don't map particularly well to specific repositories. And _blog_ and _mailing list_? Why, you're spending time on stuff most of your users will hate, not because it's bad, but because they either don't need it or would like it different.

> In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

Which is why Git is successful. That's by design, not accident. We want to, and sometimes _have to_, delete stuff.

[ginko]

>Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management.

That seems like feature creep.

[wyoung2]

Not at all. There's a lot of nice stuff that falls out of Fossil's integration of these features, things which you don't get when you lash them up from separate parts.

For example, if I have a check-in comment "Fixes [abcd1234]" I get an automatic link from that check-in comment to ticket abcd1234 from the web UI's timeline view. If I then close that ticket, the comment in the timeline view is rendered in strikethrough text, so I don't have to visit the ticket to see that it's closed.

Similarly, a built-in forum means the project's developers can discuss things with easy internal reference to wiki articles, tickets, checkins...

A recent feature added to Fossil is the ability to have a wiki article bound to a particular check-in or branch, so that whenever someone views that artifact in the web UI, they get a link to the ongoing discussion about it. This is useful when you have more to say about the check-in or branch than can reasonably fit into a comment box. This solves a common problem with experimental features, where you want to discuss it and evolve the idea before it's merged back into the parent branch.

Fossil's user management features are also highly helpful.

    http://fossil-scm.org/fossil/doc/trunk/www/caps/

With raw Git (no Github, GitLab, etc.) it's pretty much all-or-nothing, but with Fossil, you can say "this user can do these things, but not these other things." Thus you can set up a public project, giving anonymous users the ability to file tickets and read the forum but not make check-ins.

These features are as seductive as what Github, GitLab, BitBucket, etc. add to Git, but whereas those are all proprietary services with some of the roach hotel nature to them, with Fossil, you clone the repo and now you've got all of that locally, too. If the central repo goes down, you can stand your local clone up as a near-complete replacement for it.

It's not 100% because Fossil purposely doesn't clone a few things like the user table, for security reasons. You can build a new user table from the author names on the check-ins, though.

[imtringued]

>In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

I have created a lot of feature branches that contain useless commits which I then later corrected with a simple git merge --squash. Preserving those commits sounds like a drag.

[wyoung2]

You're making bisects, cherry-picks, and backouts harder by squashing history like that.

We cover this and more in the Fossil project document "Rebase Considered Harmful": https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md

[mcv]

I hadn't heard of fossil yet, but I'll definitely look into it.

[wyoung2]

The simplest way to do that is to just use it for a local project. Say, you local ~/bin directory, containing your local scripts, or your editor's config files that you want sync'd everywhere, or a novel you're writing on the side.

If you're like me, you'll find yourself increasingly wonder, "Why would I put up with Git any time I'm not forced to by some outside concern?"