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.
> bug in Fossil in trying to figure out what check-in to update to, followed by a user attempt to recover, ended up deleting edited/uncommitted files
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.)
I essentially agree, which is why I conjectured that plq was recalling incorrectly, based perhaps on second- or third-hand accounts of Shaw's problem.
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.
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.