So, how can you tell that git is no good, if it is the best of the tools available?

One particular good feature is the concept of a commit phase. It makes is crystal clear when rewriting history is allowed, and more importantly, when it isn't.

Because the UI is complicated & confusing for new users, making it easy to dig yourself a hole.

The only struggle about svn is branching (copy the whole thing) and merging was more frequent. There were many CVS systems, which I worked on, where there was no way to track who made what change in a day.

The result is that I happily keep using Mercurial locally even when collaborating with people using Git. I don't see the need to have Mercurial specific hosting. (Well, until Bitbucket finally starts working with obsolence markers so I can use Changeset Evolution).

Would that have been fixed via reflog?

What other failures have there been?

To note, many heard about Fossil because of Zed Shaw, who was bitten by the bug, and wrote about leaving Fossil because of the data loss. I wonder, therefore, if your recollection is echoes of that one report.

Fossil users pipe up in HN comments, like https://news.ycombinator.com/item?id=12665875 from a day ago, https://news.ycombinator.com/item?id=12655740 from 3 days ago, and https://news.ycombinator.com/item?id=12622773 from a week ago, so there are active users.

Yes, uncommitted changes were lost, which is bad, but not at all what someone would think when you say "Fossil lost data."

Also, that particular problem was fixed more than five years ago.

> What other failures have there been?

I've been using Fossil for my main work repositories for over two years now, and have been monitoring the mailing list for about a year prior to that, and the only things even close to that that I can think of involve crazy user actions that confused Fossil into doing something odd, typically in the UI display only, which are now prevented at the code level.

Example: It is possible to fork the trunk by working offline — its autosync feature prevents it from happening when working online, connected to the repo you cloned from — but Fossil now demands that you heal the fork after turning autosync back on, so that you don't end up with multiple active "trunk" tips. After the trunk fork is healed, one branch becomes the "real" trunk, and the other looks like an unnamed branch that's now merged.

I'm not aware of any case of committed work being lost by Fossil. In every case where someone has managed to confuse Fossil, it's always been essentially a cosmetic issue, with all of the information necessary to get the repository back to a sane state available in the SQLite DB file.

I have personally never run into such a problem. The closest I've ever come to data loss with Fossil was purely due to ignorance.

(Briefly, Fossil UI was showing me one thing when I thought it was showing me something else, and since I didn't see what I expected to see, I thought it had lost data. This was purely a newbie misunderstanding.)

Compare git:

  https://xkcd.com/1597/

My hope was that plq would clarify either with a pointer or something else more than "IIRC".

The only thing I disagree with your assessment is that "ignorance" and "newbie misunderstanding" can sometimes be due to bad design, which is a design bug vs. an implementation bug. In the Shaw case, there was a bug in the code which widened the gap between the user model and how the code actually worked, and that gap did cause data loss, just not in committed data.

Also not in a way that could be handled in git with reflog, as plq suggested.

This is a more expansive definition of "bug" than software developers, who are often more focused on the implementation than the user interaction model and as XKCD points out are very good at memorizing arcane commands, typically use.

Hipp wrote that he might have done the same thing as Shaw, which means that specific case wasn't "purely a newbie misunderstanding."

I think that was a humble and magnanimous statement which cut off some of the blame-the-user flamewar that can all too often happen in developer-driven project. As I recall, Shaw noticed this, and thanked Hipp for the way he responded. I've tried to bear it in mind since then.

> Fossil uses a transactional database for local storage, meaning that the repository is protected from corruption even if a crash or power failure occurs in the middle of a commit. Extensive self-checks protect the repository from corruption from bugs. No work has ever been lost due to a software bug in Fossil.

I've never heard that Fossil could eat your data. I don't use it now, but I've tried it for a few personal projects and liked it.

2. Git is strictly worse than both Fossil and Monotone (two SQLite-based DVCSes I have used) w.r.t. losing _committed_ changes: it doesn't do any sync calls by default, and while their documentation confidently says that fsync is just a waste of time, POSIX guarantees are not enough for safety (ext3 guarantees are enough, btrfs are not — writes to two different files are not guaranteed to be ordered by default, and I have lost commits because of a power failure, and I haven't checked what guarantees ext4 provides there).

> To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing.

no software is perfect, but fossil uses sqlite under the hood and is developed by the author of sqlite. a fairly strong data integrity guarantee in my book.

Of course, mishaps happen, bugs too. Blaming SCM is easy, blaming no-backup habits, well, that's personal.

Fossil does get progressively more potent, I can attest to this on my user experience at least from v1.19 to v1.35. Many convenience features are added, yet core remains stable.

Was the the marketing of git basically due to the fact that Linus created it?