Hacker News Reader

Comment by gkya | Hacker News Reader

Fossil does solve interesting problems, and has it's practical unique features for some use cases. And even if it didn't, having competition is nice, see clang vs. gcc.

I use org mode files for my issues and wiki-like features for my projects, and it works because my projects are very-small scaled. But having to commit issues and merge them can get boring very quickly. I haven't tried fossil, but if it has a nice quick UI for that, I might be interested.

WRT local push/pull, I don't have any problems with it in Mercurial (altho it's sth. I don't do often). What happens with git? WRT other problems, well, those are problems of all DVCSes and VCSes, so it's a bit too harsh to judge fossil by them, no?

Git command line is not inelegant, it's confusing, even at the basic level. An improvement on that is not only aesthetic. Magit is popular for a reason.

View on HN

I'm sure that Fossil does solve some interesting problems, but I don't see anyone talking about them here or on the previous HN post. I've read through the most obvious user-facing parts of the documentation, and everything seems to be focused on integrated issues, which... I don't see as a problem, or the UI improvements.

Maybe I'm just blind. Does anyone have a link or would they be willing to do a writeup on what fundamentally makes Fossil better than Git (ie. not just from a user interface point of view)?

> Git command line is not inelegant, it's confusing

Agreed, but it's not unusably bad. The question isn't whether or not Fossil can do better than Git's command line, it's whether it can do so much better that it's worth learning a new set of abstractions.

For new developers or large organizations, I can see it. But if I'm used to Git, and I can handle the bad command-line interface, why should I switch then?

Keep in mind that I'll still want to use Magit anyway, because the improvement of Magit is in no small part its Emacs integration. It kind of strikes me as a losing battle to ever market a VCS based on a GUI. When are you ever going to want to use a VCS without integrating it into your IDE? Even if Git's command-line interface was amazing, I would still want to be able to overlay `git-blame` directly onto my source.

Almost nothing is unusably bad. In VCS space, even SCCS is still better than nothing. CVS is still quite operable, OpenBSD is one of the finest codebases out there and it uses it. I actually agree you that Fossil is not a big improvement, and I guess I'll stick with Mercurial for quite a while for my stuff. But in our world of software improvements are almost always incremental, even when dubbed otherwise. I'm not trying to convince you that Fossil is an ideal tool to switch to, just that saying that it doesn't bring any improvements and then listing some problems common to other tools in the same space is a bit unfair.

Worst experiences for me have been Oracle Software Configuration Manager and IBM Clearcase.

Last I worked with fossil, their main UI for issues/wikis was all through the web-ui. It works, but it's not as streamlined as you might like. If you're looking into fossil and want an alternative interface then it's mostly up to you to either build something out of command or more easily build something out of direct queries to the sqlite database that info is stored in. I didn't see many examples of either out there when I was looking last, though I did try building something along those lines ( https://github.com/fundamental/fs-tickets ).

It also has a cli now (fossil ticket). And there's always the JSON API as well. You can also build custom queries and script it using TH.

Unless the ticket subcommand has been radically redesigned it is very clunky to use. Some of my complaints when I used the CLI last: Multiple runs of it with long parameter list are needed to navigate. Updates involving copying a UUID is a slow process. Updates commands to add comments, change ticket state, add files, etc are unintuitive. Listing ticket information does not nicely fit the dimensions of a terminal. Colorization does not appear to render in a terminal. No input validation. Cryptic documentation per sub-command.

As per the JSON API and TH scripting, they're both for the web UI (AFAIK) which I was trying to avoid if possible as it slowed down my overall workflow (though much more time has been put into making that usable by the fossil devs). As a last note TH is a bit of an oddity which I imagine may be a turn-off to other people getting started with tweaking fossil.

Fossil does have a nice UI for tickets and wiki. It's basic, it's scriptable in TH (subset of Tcl) and uses Markdown (using libsoldout).

Reply on news.ycombinator.com