
The Fossil distributed version control system - lisper
https://fossil-scm.org/index.html/doc/trunk/www/index.wiki
======
avar
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/](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...](https://www.fossil-
scm.org/index.html/doc/trunk/www/fileformat.wiki)

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.

~~~
oomkiller
This may be helpful to you:
[https://sqlite.org/whynotgit.html](https://sqlite.org/whynotgit.html),
especially the links to other comparisons at the very bottom.

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

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

------
danShumway
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?

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

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

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

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

------
antoineMoPa
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](http://127.0.0.1:8080) to try out the web UI.

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

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

~~~
buvanshak
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?

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

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

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

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

------
na85
Is there a "fossilhub"?

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

~~~
yawaramin
[http://chiselapp.com/](http://chiselapp.com/)

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

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

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

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

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

------
Lordarminius
Deleted.

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

[https://sqlite.org/whynotgit.html](https://sqlite.org/whynotgit.html)

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

~~~
btown
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/](https://rowanj.github.io/gitx/) combined with
a git-flow workflow (or anything similar) solve practically all of the
mentioned shortcomings.

~~~
chx
that's OS X only

~~~
btown
[https://git-scm.com/downloads/guis/](https://git-scm.com/downloads/guis/)

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

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

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

~~~
Boulth
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](https://github.com/google/git-
appraise)

