Hacker News Reader

Comment by avar | Hacker News Reader

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.

View on HN

> [...]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.

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

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

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

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.

"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!

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.

Reply on news.ycombinator.com