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.

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).

> Better octopus merging

I'm curious why do you do the octopus merges often. I'd probably avoid them as much as possible, mainly because small incremental changes verified by CI/CD are easier to deal with than multiple things at once. What's the benefit of merging more than one thing?

I do octopus merges very rarely, so there's no single common scenario where I default to them. It's just that Git handles them so poorly that in the rare cases where I do one the problems stick out more.

Off the top of my head:

- I was working in a large organization, and building a prototype of a feature that another team wanted to start consuming on their dev branch before it was merged into stable. We could have rebased all of their changes onto a new branch off of mine, but I thought, "meh, why not try to give their branch two parents just to see what happens." Long story short, I will not do something like that again.

- I sometimes work on Open Source code with protected branches. Once the code is merged into stable, it's all MIT licensed. Before it's merged into stable, it's not. One time I had the deceptively bright idea, "hey, why can't stable merge from two branches; one that contains license information and one that contains code?"

It's all fairly rare edge case stuff that's avoidable with a little bit of discipline and practice, but especially if I'm working with a large number of feature teams, I will sometimes notice that I'm relying on cherry-picking and rebasing not because it makes more sense than an octopus merge, but because it's just generally less dangerous to do.

Cherry-picking has its own set of problems, because when Git does conflict resolution, it cares about commit order. This means that cherry-picked commits can sometimes overwrite later changes from the source branch after they've been merged.

These are problems that I don't know how to solve, so I just avoid them. But if a VCS did solve them, I would be tempted to switch.

> Pushing/pulling directly to someone else's local repository (ie, if a remote goes down). This is always harder to do than I expect.

This can be done by specifying the URL that points to their repository's .git directory in the git push or fetch command (instead of origin). IIRC, the only complication is if you try to push a branch that's currently checked out on the remote.