The Fossil distributed version control system | Hacker News Reader

The Fossil distributed version control system

fossil-scm.org

108 pointslisper52 comments

I wish there was some post in the same vein as "Repository Formats Matter" comparing Git and Fossil. I.e. not one that describes differences in incidental UI features and how they happen to be exposed to the user now, but what the intrinsic differences are that make certain things intrinsically hard or impossible in one of the two systems.

That old post, by Keith Packard: https://keithp.com/blogs/Repository_Formats_Matter/

I've read through the documentation on the Fossil file format: https://www.fossil-scm.org/index.html/doc/trunk/www/fileform...

Maybe I'm just being dense, but e.g. in the case of the wiki which Fossil advertises as a core feature over Git, it's not clear to me how it wouldn't be implementable in a similar way in Git by some convention of creating commit objects & having some web UI that understands that convention, and if so the real differentiation is just in the porcelain part of the UI.

> [...]but what the intrinsic differences are that make certain things intrinsically hard or impossible in one of the two systems.

Not a complete answer, but I like to think about it this way:

git was made by a file-system expert and is file-system based and Fossil was made by a database expert and is SQLite based. So a lot of the limits can probably derived from the limits of and differences between old school file systems and traditional relational databases.

I wrote old school and traditional because when is comes to modern file-systems and modern databases the lines get blurry.

This may be helpful to you: https://sqlite.org/whynotgit.html, especially the links to other comparisons at the very bottom.

The examples he presents to compare the features of GitHub to Fossil, not git itself.

Fossil has a GUI built-in that makes visualizing the repo easy. There are tools for Git that provide similar functionality.

1. "Git makes it difficult to find successors (descendents) of a check-in" - Use a Git GUI like SourceTree and it's really damn easy to jump to a commit and review the entire graph up and down using links to jump to parent/child commits (even multiple parents for merges.

2. "The mental model for Git is needlessly complex" - Again, a Git GUI can make it really easy to keep track of "changed but not ready to commit, changed and ready to commit, local and remote branch"

3. "Git does not track historical branch names" - The example he provides here shows a visual graph in Fossil of the branch history. The exact same thing is available in Git via "git log --graph --all --decorate" or a GUI that shows the graph.

4. "Git requires more administrative support" - "apt install git" or "brew install git" or most systems come with it pre-installed. Windows is a bit more annoying.

5. "Git provides a poor user experience" - "Just memorize the shell commands". Again, there is tooling available for Git to remove this requirement.

It seems to me that his main complaint is that Git doesn't provide a GUI out of the box to make visualizing the repository easier. I get that, but there are enough tooling options available that it becomes a non-issue. SourceTree is a native app for Mac and Windows and there are various other GUIs even CLI GUIs for Git that users have a lot of flexibility. Fossil would seem to require them to use the GUI provided by Fossil whether they like it or not.

I'm not bashing on Fossil at all. I'm just saying that his arguments here show a lack of knowledge about the available tooling for Git and not fundamental advantages of Fossil over Git.

> 3. "Git does not track historical branch names" - The example he provides here shows a visual graph in Fossil of the branch history. The exact same thing is available in Git via "git log --graph --all --decorate" or a GUI that shows the graph.

No, that Git command only shows current local and remote branch heads, not the branches to which a commit historically belonged. If you look at the link he posted, that git hub page provides that same info. AFAIK Git does not store this historical information. If you look at the example links he provides, in Fossil each commit has tags saying what branch(es?) it belonged to.

I do agree with the rest of your points. I use a combo of GUI for viewing current state and easily adding/removing file, I also use more complicated git commands when I need to do stuff that isn't easy in the GUI I use.

> Use a Git GUI like SourceTree..

It quickly fails to scale. The issue is when you want to use commands to find the successors and build some processing over it..

>"The mental model for Git is needlessly complex" - Again, a Git GUI can make it really easy to keep track of "changed but not ready to commit..

That is a very limited situtation. In the course of using a VCS, for a long running project, one encounters numerous situtations where having a complex mental modal quickly feels exhausting...

> The exact same thing is available in Git via "git log --graph --all --decorate" or a GUI that shows the graph.

No. it is a bit different. In Git, branches can easily jump around, and the commits that were previously under a branch will have no information in them regarding which branch they were originally made..

>. Again, there is tooling available for Git to remove this requirement.

Again, you are not thinking like a power user. GUI's only works if you follow some predefined "happy path"..

> I'm just saying that his arguments here show a lack of knowledge about the available tooling for Git

To me, it seems that you are lacking enough experience to identify what the author is talking about..

For full disclosure: the creator of SQLite is also the creator of Fossil, so this is not at all an unbiased comparison.

"The mental model for Git is needlessly complex". I still cannot understand this one. I find Git terribly simple: you just have a hash DAG of commits, each of which has an associated hash tree of files. Branches and tags are just labels for individual commits (branches "move" and tags "don't"). The index is just another commit, only difference is that it has yet attached permanently to the tree; most of the time it is virtually transparent (just use "commit -a"), and when it is not it is very useful (the various "-p" flags). Pushing commits across repositories mean to update labels in the remote so that they match the local ones, and Git will take care of actually moving objects so that remote remains consistent. How can it be simpler than this?

I have not yet found such a simple description for any other DVCS, although I admit that given that Git is everywhere nowadays has not motivated my to do much research.

In the particular case of Fossil, if I read https://fossil-scm.org/index.html/doc/trunk/www/concepts.wik... (which is supposed to explain the concepts), it already begins explaining workflows, specifying that I have to choose between two alternatives, for which I do not even have a complete explanation (what happens if I divert from the suggested workflow?). Now that is what I call complex!

To be fair, the only compelling reason I got from that article is that they use Fossil and not git because the creator of SQLite is also the creator of Fossil.

I've seen that and commented on it when this was discussed on HN 3 days ago: https://news.ycombinator.com/item?id=16806372

In GitHub and GitLab every wiki is a git repository, so it's already implemented.

fossil is used as the intermediate format for the NetBSD CVS -> git and mercurial, I assume because its format is good? Only https://github.com/jsonn/ could say for sure, though.

It's not terribly difficult for me to track my issues, or a wiki, or even a static site alongside my source code just via plain text (and in fact I usually would prefer to). I can get the parent of a commit in Git, and if I can't remember the specific command I can just add an alias. Git's interface is hard to teach and unintuitive, but now that I know it, it'll be initially a net loss in productivity for me to learn anything else even if it's way more intuitive.

I guess what I'm getting at is that even if Fossil is better than Git, the problems it's solving don't seem to be particularly urgent to solve. Less complexity is good, but it would need to be considerably more elegant than Git to make me not want to use a VCS that's basically standard now.

I don't see anything in the FAQ, overview, or questions page where I'm thinking "Oh, this is something I couldn't do in basic Git." For a large organization I can see the benefits of simplifying, but as a developer I feel like I'm missing the hook.

Off the top of my head, Git improvements that I regularly do want:

- Large file support and binary file support. LFS exists, but is clunky and annoying to work with.

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

- Better octopus merging; once commits in git have multiple parents, there are sometimes unexpected complications that can arise in future merges.

Does Fossil solve any of those problems?

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.

Fossil has a debian repo, so for lazy debian users like me:

    sudo apt-get install fossil
    fossil init test
    fossil open test
    fossil ui

Then, as the command-line message says, you can navigate with your browser to http://127.0.0.1:8080 to try out the web UI.

Git, to me, feels like a purposefully obfuscated tool. Using git is painful to me in two levels. First one is the actual pain in using the tool. Second one is the disturbing realization that this tool became the defacto standard for version control system, which indicates a systemic issue within the programming community, where something, despite its obvious flaws and availability of superior options, can end up winning over the competition...

Maybe you should acknowledge the fact that others may have different tastes than yours, instead of calling for "system issues" because you do not like the mainstream tool (which is perfectly fine, in itself).

So I not what you mean so that I can show will next or could be so.

Is it a matter of taste that the above sentence is well constructed or not?

Fossil also has version control for issues. That didn't become very popular in other applications. We're now thinking about having issues function like Google Docs. You only get linear history but you gain real-time collaboration.

This was big on here last week, regarding why SQLite developers use Fossil not Git: https://sqlite.org/whynotgit.html

Link to discussion from 3 days ago https://news.ycombinator.com/item?id=16806114 (600 comments)

I was going to say, didn't we all just discuss this?

Is there a "fossilhub"?

I think that would be a good way to drive adoption.

http://chiselapp.com/

Thank you. I was not aware of this. I plan to add them into searchcode once I figure out how to integrate with fossil.

Thank you! I didn't know something like this even existed for Fossil.

EDIT: Typo

I didn't make the "github" connection first because I thought you were making a play on "fosshub". If it provided release binaries, it can work both ways!

How does Fossil's underlying storage / change tracking mechanism diff from that of Git, Mercurial, or Vault?

They use a SQLite database as their underlying storage. (It is written by the author of SQLite.)

Interesting; just like monotone. Which I think should have become the de facto standard instead of git.

Does anyone else see a fairly strong network effect with versioning software? Most TCL users seem to use fossil. Most web developers use git. A bunch of impressive, older software uses svc. Huh.

Deleted.

As your sibling already replied, you'll likely find answers here:

https://sqlite.org/whynotgit.html

And HN discussion (with over 600 comments) here: https://news.ycombinator.com/item?id=16806114

Almost all of these are quarrels with Git's UI/UX, not with its model of representing data. Tools like https://rowanj.github.io/gitx/ combined with a git-flow workflow (or anything similar) solve practically all of the mentioned shortcomings.

GitX is one of those great, simple tools that I have used for years. I do actually love the Xcode treatment of a git UI as well, but it's overkill in most cases.

that's OS X only

https://git-scm.com/downloads/guis/

One of the big things pushed with Fossil is that you get issues and a wiki built in, compared to Git, but when you consider it there's nothing preventing you from tracking issues and keeping wiki pages inside a Git repo as well. All that Fossil offers is some extra porcelain over its storage layer, which could be offered through extra tooling for Git as well.

> All that Fossil offers is some extra porcelain over its storage layer...

Well... the tickets are things that live in the repository like a commit[0], so can reference other entries, and are referenceable by other entries, in a first class way. So “just porcelain“ or a “simple matter of programming” for git, in the dismissive sense.

[0] https://www.fossil-scm.org/xfer/doc/trunk/www/tickets.wiki

> All that Fossil offers is some extra porcelain over its storage layer...

Well... the tickets are things that live in the repository like a commit, so can reference other entries, and are referenceable by other entries, in a first class way, so it’s a “simple matter of programming” for git in the dismissive sense.

These features are possible right now on the backend of git to be implemented. There's nothing blocking git to add these things. What git would need is a front-end (remember, the cli is a frontend) to implement these.

Don't get me wrong, I do agree fossil is adding some new cards to the table. I just think it would be better implemented as extensions to git than a new system made from scratch.

Yep, this is completely possible to implement in git. Fossil has it built-in already, that's good.

For anyone who wants to see what's possible using low level git tools: https://github.com/google/git-appraise

Reply on news.ycombinator.com