
Fossil vs Git - afiori
https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki
======
jordigh
I'm a big, huge fan of recording what should have happened instead of
recording every typo and forgotten semicolon in your history. There's a
difference between draft commits and published commits. When I'm reading
published commits, i.e. history, I just want to know your intent, not your
typos. So what are the tools that Fossil offers to make sure I don't have to
see your typos in the history?

~~~
gugagore
I'm also a big fan of not deleting data. I don't like squashing commits, for
example. But I also want to be able to see high-level intent.

If instead of "squashing", it were "grouping", I'd be happy. I could
encapsulate a bunch of messy commits that I made while I didn't know what I
was trying to do. The intent would be clear at a higher level, but if you want
to dig in to see what it actually took me to achieve that, you can see all my
experimentation by looking at the commits inside the group.

Groups should be able to be nested, of course.

The only way I know how to achieve this in git is my relying on no-fast-
forward merges. There's a post detailing this approach [1], but unfortunately
a lot of git tools don't support this workflow that well. I haven't gotten it
to work well in gitlab, for example.

[1] Git First-Parent-- Have your messy history and eat it too :
[http://www.davidchudzicki.com/posts/first-
parent/](http://www.davidchudzicki.com/posts/first-parent/)

~~~
jordigh
You misunderstand me. Almost everyone does. I do not think you should squash
all of your changes into a giant hairball commit, and I don't think first
parent (which is effectively the same thing) solves this problem either.

I think _each_ of your commits should be _individually rewritten_ until each
commit makes sense and tells a single, indivudal story that makes sense on its
own, while at the same time be completely atomic and _as small as possible_.

You created a new function? That's one commit. Take a moment to explain why
this function is going to be useful in future commits.

You called that new function from several new spots? That's another commit.
Explain why each of these calling sites requires this function.

You decided that there had to be some style and whitespace changes? That's
another commit. This one can go without explanation.

You found an old bug along the way that can be fixed with a one-line change?
That's another commit. Hey, nice catch. Perhaps a few lines about this bug and
why your small change fixes it?

Together, these are all individual scenes of a larger story. But the larger
story doesn't need the behind-the-scenes of how you came up with these scenes.
I don't need to see all your drafts of each scene. I just want the final
scenes that make up the final story.

~~~
atombender
Ideally it should be this way, but it's impractical in reality.

It requires that you either stop your development workflow to commit as you go
along, or that you untangle all the pieces after they're already entangled.

If you commit as you go, it's an expensive mental switch to fire up git and
also run all the tests (since surely part of this workflow is to apply the
principle that no commit should ever break the build). You also take an extra
productivity hit every time you change your mind about something a little
later (e.g. you added the function getFoo() but realize it should have been
called findFoo()).

If you work for a while and then try to bundle up small, atomic changes, that
can also be very difficult. Tools like git group together contiguous chunks of
changes when committing, and prying them apart later can be difficult. I often
do this with a combination of "add -p" and then "stash save -k" to temporarily
get rid of things unrelated to what I'm committing, but it's a chore. During a
selective "add -p" session you have to mentally keep track of what belongs
together, thus what dependencies are between every chunk you're adding.

Committing as you go is easier, but it's slow, and doesn't work well when
you're working across many files with a big change that introduces new
semantics in a lot of places. _Both_ techniques require that you keep track
mentally of which parts are related, of course.

~~~
jordigh
Untangling is what I mostly do. I consider the untangling my own internal code
review. I need to read my own diff and figure out what goes where and what
each part does and why it's necessary. My commit messages are then my own code
review comments.

I figure if I don't carefully read my own diff, why would anyone else? And
once it's untangled, I am hoping others will find it easier to read too.

Git doesn't provide as many tools as I would like to make this process easier.
It's partly why I don't use git. Mercurial's absorb command helps a lot: it
absorbs changes from your working directory into the appropriate draft commit
that corresponds to the same context:

[https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-
ch...](https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-
mercurial-4.8/)

Wait, it appears someone finally ported it to git:

[https://github.com/tummychow/git-absorb](https://github.com/tummychow/git-
absorb)

~~~
atombender
That's a cool script. I will definitely try that. Augmenting commits by doing
partial commits then fixing with "git rebase -i" and squashing with "fixup"
takes so much time and mental effort just to not make a mistake.

It still doesn't solve how to disentangle changes that have become
interdependent. For that you have to concentrate on committing atomically and
planning ahead a lot.

------
bensummers
I choose fossil at a time when it wasn't clear which one of fossil, Mercurial,
or git would "win".

I choose it because it had a very clear and easy UI, guided you towards a way
of working that is suitable for small teams (ie 99.99% of all projects), and
had an approach to history which made it unlikely you'd ever accidentally lose
work.

The only thing which has ever made me sad about my choice is pressure from
people who think everyone should use git.

It also has some very nice features, like being able to give you a full web UI
just by running it as a CGI process on a web server.

It is worth trying (and it can import and export git history). Just remember
it's not git.

~~~
Drdrdrq
Been there, but with Mercurial. We chose it because it has sane CLI interface
(as opposed to git), but eventually had to switch because we wanted to use
GitLab. Not much difference all in all, except with git I still need to search
the net to find a proper command, while with hg I could usually guess it and
just checked help for confirmation. It saddens me that git won... Awful UX.
But they had GitHub and now GitLab.

------
jlebar
_Git: One check-out per repository_

 _Fossil: Many check-outs per repository_

git allows multiple checkouts per repo.

Official docs (good luck): [https://git-scm.com/docs/git-
worktree](https://git-scm.com/docs/git-worktree)

Random person's blog that explains it more clearly:
[https://www.saltycrane.com/blog/2017/05/git-worktree-
notes/](https://www.saltycrane.com/blog/2017/05/git-worktree-notes/)

~~~
randallsquared
I have no idea what use case is satisfied by git worktree, based on that blog
post. In the case that you desperately needed to have two branches checked
out, why not just clone twice?

~~~
raimue
With multiple clones, you would need to remember to update each clone regulary
not only from remote, but also push/pull locally in case you want to compare
your state with other branches.

A 'git checkout' on a large repository such as the Linux kernel may take a
while (bound by I/O performance). Regulary switching between branches with
many changed files becomes annoyingly slow.

If you keep multiple clones, you actually keep multiple copies of the full
history, which seems like a waste of disk space (yes, deduplicating
filesystems exist, but are rarely used).

git worktrees are also very useful if you have unfinished on a release branch.
You do not have to make temporary commits or stashes you forget about, you can
just leave the modified files as they are and switch to a different worktree
to continue your work on another branch.

~~~
Groxx
`git clone --local` does hardlinks, space usage is quite low, so I'm not
really sure that part holds up. Maybe in Windows? Switching branches can
definitely be slow tho, yeah. Do worktrees change that somehow tho?

From all I've read so far (quite limited!) they just sound like replacements
for `git stash` or making a temporary commit / branch, but with a new set of
commands and rules to learn. I don't find `git commit -am tmp` (literally, I
just do that) to be particularly worth optimizing further, and worktrees so
far sound like substantially more work.

\---

edit: ah, yeah, updating multiple clones is definitely annoying / easy to
forget, totally agreed there. that alone might make it worthwhile. I only need
it like once a year so I probably won't, but I do know some coworkers who do
it a lot.

~~~
raimue
git worktrees can also be useful if your build system needs different
arguments per branch. For example if you keep multiple release branches
installed side-by-side on your machine, it is easier to just run `./configure
--prefix=/opt/release-X.Y` only once on a worktree instead of repeating this
procedure every time you switch branches. That way you can even keep all your
object files around and save the time to compile them again.

The same also applies to languages such as Python or Node.js, where you might
have a different set of dependencies depending on the branch and don't want to
regenerate your virtualenv or node_modules on every branch switch.

~~~
Groxx
aaahh, so it can track un-tracked files too? that I can definitely see being
useful - the lack of a "local" / "remote" git ignore split makes this kind of
thing hard :|

(yea, there's .git/info/exclude, but you can't add it to a branch and have it
only exist locally. and it has weird interactions when something becomes
tracked later.)

------
tux1968
One of the bullet point advantages listed for Fossil of allowing multiple
checkouts per repository is also supported by Git. There has always been a way
to do it, but since Git 2.5 or so, the "worktree" sub command was added for
this purpose.

~~~
emerongi
Huh. I've just used another git clone of the repo, but the worktree command
seems to fit my uses very well. Thanks.

~~~
paulddraper
Git clone is still a fine solution, and the one I prefer.

Worktree adds the ability to share config and save disk space.

~~~
fiddlerwoaroof
The other advantages of worktree are: you can update the remotes of all the
checkouts at once with git fetch and you can see all the places your
repository is checked out with a git command.

------
randallsquared
From the features in Fossil and not in git:

> Branches in Fossil have persistent names that are propagated to
> collaborators via push and pull. All developers see the same name on the
> same branch. Git, in contrast, uses only local branch names, so developers
> working on the same project can (and frequently do) use a different name for
> the same branch.

Since the default is to use the name from upstream when checking out a branch,
the vast majority of the time devs working in git also use the same name for a
branch. Given that, this seems better stated as a feature for git (Easily
Renamed Branches, perhaps).

~~~
cryptonector
That is very silly of the Fossil community. On the surface Fossil branching is
a lot like Mercurial branching, but under the covers it's just like Git's
branching: branches are just bookmarks for commits. And Git very much has
local tracking branches (that track upstream branches), so it's as Fossil-like
as you want, but doesn't pretend to enforce a merge-only workflow.

That's really the bottom line when it comes to Git vs. all the others: Git
doesn't enforce a merge-only workflow, not even as a default, while all the
others generally do.

Mercurial, for example, resisted adding cherry-pick and rebase for the longest
time (just like Fossil), and when they finally added it they had to do it in
gratuitously different ways from Git (e.g., you can rebase, or rewrite
history, but not both at once) because they are so damned opinionated about
how we all should do do our work. So now Mercurial has rebase, and it has
"bookmarks" (i.e., Git-style light-weight branching), but you still can't
really use it without heavy-weight branching, and you can still get into
trouble where you end up with multiple tips on a branch, and it still tries to
hide the machinery underneath, which makes it difficult to reason about.

Fossil also tries to hide the machinery underneath it, and that's its big sin.
Just like Mercurial. The irony is that under the covers Fossil is a lot like
Git but with a fabulous SQL store.

I believe the Fossil maintainers simply do not understand rebase. Or why it's
necessary when you have thousands of people working on a codebase.

At Sun we did rebasing long long before that term existed, way back in the 90s
(well before I went to work for them), and we did it using ancient tech known
as Teamware. That's where Larry McVoy got some of his ideas, and thence Linus
Torvalds. Later, when we selected Mercurial, we ended up doing rebase in
Mercurial long before Mercurial adopted the feature -- we still didn't call it
that, and it was all scripted. Indeed, you can rebase on Fossil just fine, if
you're willing to script it around Fossil's primitive cherry-pick (which,
incidentally, is pretty much how rebase is implemented in Git, though nowadays
it's not scripted).

My theory is that Git -or any VCS- is only difficult to understand if you
insist on abstractions that hide its mechanics completely. Abstractions are
absolutely critical to what we do, so this might seem a bit incongruous, but
I'm not asking for no abstractions here, just that their being leaky is
actually a very useful thing in the context of VCS.

------
Vinnl
> Fossil, in contrast, puts more emphasis on recording exactly what happened,
> including all of the messy errors, dead-ends, experimental branches, and so
> forth.

I think this is an interesting distinction. The question is: what is the
function of the history? Is it to document what happened - and if so,
shouldn't every keystroke be committed? Or is it to document which changes
relate together, and e.g. should be reverted together? Or perhaps something
else entirely?

One thing that isn't mentioned is whether Fossil supports working offline as
well as Git does. My impression from this page is that it emphasising creating
every branch on a server as well, which implies you need to be connected? If
so, I'd consider that a "missing feature" as well, as it's something I use
regularly enough and that's important enough that it'd be something I'd miss
if it weren't there.

~~~
messe
> One thing that isn't mentioned is whether Fossil supports working offline as
> well as Git does. My impression from this page is that it emphasising
> creating every branch on a server as well, which implies you need to be
> connected? If so, I'd consider that a "missing feature" as well, as it's
> something I use regularly enough and that's important enough that it'd be
> something I'd miss if it weren't there.

The way fossil works is that by default autosync is turned on, which means
that _if_ you are connected to the internet all of your commits, wiki and
issue tracker changes are synced to the server.

In the case that you're not connected, everything still works as expected, and
will sync back up next time you're online and try to commit or just run
`fossil update`.

~~~
Vinnl
Thanks, that makes sense then.

------
booleandilemma
Your commit history should read like a published novel, not a first draft.

I think I might’ve read something like that in the Pro Git book and it rings
true with me.

The philosophy of Fossil is to preserve the full history, which I think is a
mistake.

~~~
afiori
A nice feature would be the ability to group and split commits afterwards;
like adding a "novel branch". So that you could keep both the exact history
and a parallel high level description.

~~~
grive
Your high-level description resemble a cover letter used on some open-source
project to introduce a patch series, justifying the changes.

You could achieve the same by using an empty commit, or tracking those in the
bug tracker.

DCVSs are already complex enough, this just seems like scope creep, trying to
emulate a feature that is actually part of another tool (the bug tracker or
the mailing list, depending on the structure).

Another issue is that it would foster a mentality where people would simply
don't care about the exact history and push really badly structured commits,
relying on the second-level history to explain their work. Except that if
someone publishes something, it's not for this person, it's to be read by
other people. The dev could keep a local branch with all their commits if they
are so inclined, but that should never be sent to a shared server.

Most people are already bad enough at writing proper commits and dividing
their work, I think your feature would make it worse.

------
skywhopper
Ugh. Certainly there are things that git could do better but reading this
makes me want to run far away from Fossil and never look back.

You can argue about whether “the Unix philosophy” is best for specific tools
like version control, and maybe you can argue that “the Unix philosophy” isn’t
really about simple vs complex tools. But I don’t think I’ve ever heard nor
would I think you could find evidence that the Unix philosophy is “it just
works”. That claim makes me pretty certain that this is a tool I want to avoid
at all costs. And the tone of the rest of this article confirms it.

~~~
cryptonector
My feeling as well. It's sad because Fossil underneath the covers is a lot
like Git, but with a SQL RDBMS as the store. Fossil's design is much more
powerful than Git's for that reason alone. But that super-opinionated attitude
they have is a disaster. Run away.

------
joshka
> Git puts a lot of emphasis on maintaining a "clean" check-in history.

This seems like an inaccurate phrasing of this. Git (the tool) doesn't
specifically emphasize this, but it does support this as a possible approach
without excluding the other approach. Many teams have settled on development
approaches with git that do indeed emphasize this, but not every team does. If
you want to show your work, you sure can, but unlike fossil, git does not
force this upon developers. Like the article, I don't see either approach as
right or wrong, but know that I prefer the clean history approach rather than
every typo commit ever.

~~~
pseudalopex
Git's linear presentation of history encourages rebasing or squashing.
Mercurial keeps the branch structure, which has the advantages of both
squashed and unsqusahed commits.

~~~
joshka
I use the following fairly regularly (aliased):

    
    
        git log --graph --oneline
    

I can understand how you could see this as an advantage, but I see forcing
this on the developer as more of a disadvantage. I literally never want to see
in any history commits with junk attempts to fix something. After the fact,
these are the least interesting things to me.

~~~
pseudalopex
That doesn't keep the branch names. It also doesn't help bisect complex
merges. Git may be better at that now, to be fair. So many projects rebase or
squash that I haven't had to do it in a while.

Mercurial can rewrite history in the same ways as Git.

I never want to see junk commits, but I can't force other people to spend time
cleaning them up. Squashing cleans them up quickly but loses useful
information.

------
blacksqr
In my experience, feature sets tend to converge within product categories, but
I'm happiest in the long term with the program whose original design decisions
I'm most sympathetic with.

In fossil's case this was architectural simplicity, an easy-to-use basic set
of commands with a discoverable set of expanded commands that always seemed to
meet my needs as they cropped up, collaboration features in the pre-GitHub era
were killer. There are a few discrete layers of hackability for customization
with minimal risk of blowing your project away.

Fossil still meets my needs admirably, and I stick with it even though it's
harder to make the case for it in the current era of feature convergence.

~~~
cryptonector
Fossil's design and implementation are indeed admirable. Its insistence on
merges is not.

------
nharc
As someone currently working in a project where parts are managed with git and
others with fossil, I have a strong preference towards git. One major issue
with fossil is the non-existent ecosystem. It simply does not integrate well
with other frameworks and tools (e.g. Yocto/OE). Migrating to git entirely
would be much better for the team and workflow as a whole, but unfortunately
the seniors who are using fossil are quite hostile towards git, for mostly
political reasons. The irony is that they have big performance issues with
fossil, precisely due to the fact that fossil records everything and the
push/pull commands sync the entire repo, not just one branch.

Fossil also lacks an equivalent to git submodules, which should be added to
the list of features found in git, but not in fossil.

------
deepaksurti
The Fossil Logo [1] resembles so much the Lisp Lizard! [2]

[1] [https://fossil-scm.org/fossil/doc/trunk/www/index.wiki](https://fossil-
scm.org/fossil/doc/trunk/www/index.wiki)

[2]
[http://xahlee.info/UnixResource_dir/writ/logo_lisp.html](http://xahlee.info/UnixResource_dir/writ/logo_lisp.html)

------
shrmn
I agree with those who said they prefer git's "clean" commit history.

------
achiang
The comparison table in section 2 could just as easily live in the git docs,
under a page called "why use git instead of fossil".

------
kurtisc
git-worktree seems to give git the multiple-checkouts feature.

Also, this page seems to do the common but frustrating thing of advertising
how something is implemented as a feature. I'm sure it's very interesting to
the developers that it uses a database in the backend or that your side-
project is written in a niche language but, as an end user, I just don't care.

~~~
SQLite
Here is an attempt to clarify why I think implementation does matter:
[https://www.sqlite.org/whynotgit.html#git_makes_it_difficult...](https://www.sqlite.org/whynotgit.html#git_makes_it_difficult_to_find_successors_descendents_of_a_check_in)

When the design of a system makes something difficult, people tend to avoid
doing that thing. The Git data design makes extracting some kinds of
historical information difficult, with the result that many common tools (ex:
GitHub) don't bother. This reduces the information available to users,
resulting in reduced situational awareness.

I make no claim that Fossil is perfect in this regard. My only claim is that
Fossil is better.

Whether you use Fossil or not, I don't much care. But I really would like you
to understand some of the features of Fossil that (I think) make it better
than Git, and perhaps start adding some of those features to your favorite
VCS, be it Git or something else. Understand the general concepts, then port
those concepts to other systems.

~~~
cryptonector
Fossil is better. Because it has a better design. Because it uses SQL (which
makes it possible to write queries on the fly in ways that cannot be done in
other VCSes). The use of SQL, and Fossil's use of fairly generic SQL, allowing
the use of RDBMSes other than SQLite3, is brilliant, and would make it trivial
to make Fossil scale better than MSFT is making Git scale, though with the
caveat that you'd probably still end up wanting things like a Bloom filter for
speeding up file-level log/blame, but you could probably make Bloom filters a
transparent, RDBMS-level query optimization.

Fossil is worse. Because it doesn't have a CoW design in the format of its DB,
though it does have a CoW design in its SQL schema. However, because SQLite3
is so good at handling power failures and such, this has not been a big deal
(and indeed, Git has had more problems there owing to its ad-hoc storage
model). This, of course, could be fixed by adopting a CoW backend for Fossil.
This problem is hardly fatal.

Fossil is worse. Because of its insistence on merge workflows and not
implementing rebase.

Fossil is worse. Because it has minimal mindshare. Mindshare is absolutely
critical. The lack of rebase support is part of the reason that Fossil cannot
get the kind of mindshare that would allow it to replace Git. And it may well
be too late, but you never know.

It turns out that rebase is the more critical thing for me and many others. I
think the Fossil community doesn't know it and doesn't get it because the
projects it deals with don't have thousands of developers active every day.
And, of course, rebase is really just a feature that can be built by using
scripting on top of a cherry-pick primitive (which Fossil does have), so
there's no real excuse for not having it.

Incidentally, GitHub used to also insist on merges in its browser UI, but
eventually they added the "rebase and merge" feature.

Mercurial too resisted rebase. Boy did they. And they gave in and implemented
it. Ironically many people rebased in Mercurial long before the feature was
adopted -- we did, in Solaris engineering, a dozen years ago.

My prediction is that Fossil too will eventually support rebase (out of the
box) for the same sorts of reasons that all other VCSes have tended to get it.

If I had to use Fossil, the first thing I'd do is script a rebase around
cherry-picking. Because I could, because the market demands this feature,
because it's a built-in feature of competing, more-successful VCSes, Fossil
ought to adopt it. You wouldn't have to use it. You might have a way to turn
it off on a project-by-project basis. But the rest of us should get to use it
on our projects.

All in all, I neither use nor recommend Fossil. But I am envious, and I would
use it, if it had rebase.

------
anilakar
Funny how they say that Git uses a "Bazaar-style development" process when
Bazaar literally is another VCS.

I'm also not convinced it's a good idea to merge your bug tracker and version
control.

~~~
jepler
There's a famous comparison of development styles that in turn predates the
Bazaar software by years if not a decade.

~~~
solomatov
Here's the wikipedia article about this work:
[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)

------
palerdot
> Push or pull a single branch

> The fossil push, fossil pull, and fossil sync commands do not provide the
> capability to push or pull individual branches. Pushing and pulling in
> Fossil is all or nothing. This is in keeping with Fossil's emphasis on
> maintaining a complete record and on sharing everything between all
> developers.

This is a kind of deal breaker if it just pushes all of my private WIP
branches to remote. Is there any genuine use case for this kind of
functionality? Apart from that, this looks interesting.

~~~
bch
Fossil does have private branches[0] and the recommended way to publish
private work is to integrate it into a non-private branch and sync as usual.

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

------
aboutruby
Always surprises me how Fossil is popular on HN but very much not outside a
few projects (e.g. sqlite)

~~~
SQLite
Some data:

The fossil-scm.org server gets between 1500 and 2000 distinct human visitors
per day on weekdays. (Lower traffic on weekends. Robots are excluded from the
count. "distinct" means visitors having different IP addresses.) This is
perhaps orders of magnitude less than git-scm.org (I'm guessing - anybody have
stats?) but it is also non-trivial. With ~1750 visitors per day _somebody_
must be using it. And I would guess that most actual users do not visit the
site daily. (When was the last time you visited git-scm.org?)

FWIW, today has already seen in excess of 10,000 distinct human IPs, likely
due to this HN post.

~~~
aboutruby
> When was the last time you visited git-scm.org?

Like most people, I go to Google which then redirects me to the correct Stack
Overflow question/answer the most often. I think git-scm.org is mostly a guide
to get started and the reference documentation.

------
avar
Previous discussion 9 months ago about the "Why SQLite Does Not Use Git" page
at [https://sqlite.org/whynotgit.html](https://sqlite.org/whynotgit.html)
which has much of the same info:
[https://news.ycombinator.com/item?id=16806114](https://news.ycombinator.com/item?id=16806114)

------
intertextuality
> SQLite uses cathedral-style development. 95% of the code in SQLite comes
> from just three programmers, 64% from just the lead developer. And all
> SQLite developers know each other well and interact daily. Fossil is
> designed for this development model.

Is this not terrifying? I've always thought the distributed nature of git is
part of why it's so incredible. Not relying on a few handful of individuals.

------
joshka
> The ability to show descendents of a check-in.

This is interesting. I wonder if the same thing could be achieved fairly
simply in git though by keeping an extra area in the .git folder that handles
reversing / denormalizing the DAG for some of the things that these reports
show.

Microsoft are innovating in this area (bringing the improvements that they
have in VSTS to the client). There's a good series of blog posts on this at
[https://blogs.msdn.microsoft.com/devops/tag/git/](https://blogs.msdn.microsoft.com/devops/tag/git/)
(first article
[https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...](https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-
the-git-commit-graph/))

------
butterisgood
fossil is also the name of a file system server on Plan 9 that dealt with
hashes on the venti archival storage server.

[https://9fans.github.io/plan9port/man/man4/fossil.html](https://9fans.github.io/plan9port/man/man4/fossil.html)

------
brobdingnagians
I think it really comes down to preference. Both work well and for different
reasons and styles. Including tech notes and docs into the VCS could be nice,
if you use it, but like most project management, it comes down to how you
work-- that's one reason why there isn't a one-size-fits-all project
management product that is infintely better than any other offering. There are
plenty of times I wished I had something like the embedded tech notes to
explain design decisions. I use git myself currently, but I've wanted to dip
my toes into fossil for awhile to see if it matched my workflow. I think
storing the whole repo in an SQLite database was brilliant-- self contained
and you don't have a problem slicing the data to get things like all parent
commits or descendant commits.

------
orev
As someone not versed in either, how much does not being able to track changes
forward through the history matter? It sounds like that might be pretty
important, but git’s popularity would seem to indicate that it doesn’t really
matter in practice?

~~~
shawkinaw
I have to say, I’ve used Git for many years now and I’ve never, ever, ever
wished for this, nor even knew it wasn’t possible. So this seems like a silly
thing to claim as an advantage for Fossil.

~~~
SQLite
I never thought I needed bisect, until I had it. Now I can't live without it.

~~~
shawkinaw
Yeah totally fair point. I figured there’s probably some usecase I haven’t run
into for this feature. Still, I think it says something that I’ve never missed
it despite some fairly advanced Git usage.

------
joshka
> The fossil all command

In git, this is pretty much a oneliner script dropped in your path and named
`git-all`.

Something like (typing from memory on my non-work computer):

    
    
        #!/bin/bash
        find . -type d -depth 1 -exec git -C {} "$@" \;
    

Which allows any of the following to just work (I usually alias these
commands):

    
    
        git all status
        git all status --short --branch
        git all pull --rebase

------
SQLite
Additional links for the curious:

[https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki](https://fossil-
scm.org/fossil/doc/trunk/www/quotes.wiki)

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

~~~
Terretta
I’ll pull what I consider an important quote into this thread:

> _”SQLite uses cathedral-style development. 95% of the code in SQLite comes
> from just three programmers, 64% from just the lead developer. And all
> SQLite developers know each other well and interact daily. Fossil is
> designed for this development model.”_

FWIW, I consider this an extraordinarily productive development model.

Agile may be about People and Interactions over Processes and Tools, but (and
it’s too often forgotten) all dev must first be about effective output in the
problem space. So, how do you optimize ratio of Outcomes to
People/Interactions/Processes/Tools? This model.

FWIW, I also consider Linus’ and Guido’s “BDFL” approach a way the bazaar is
channeled back into a cathedral.

------
cryptonector
[https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...](https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b3996549748d)

------
zzo38computer
I use Fossil for my own projects; I find it is less confusing than Git.
However, I use cathedral style for my own projects, so that helps; I manage
all of the code by myself but nevertheless will allow anyone to look at the
code, make their own version with their own modifications (a fork of the
project) (and do whatever they want with their own copy of the code), make bug
reports, and submit patches for me to review, but not to directly write to the
code repository (only I do that).

------
stesch
Would you recommend using fossil for Unity3D projects? Needs to exclude
certain files and being able to deal with binary files.

~~~
rwbt
Just giving my experience - I working in rendering graphics and use fossil for
version control. Some of my repos are more than 100GiB in size and fossil has
no problem with it. Fossil handles binary files adequately but the only catch
is file size is limited to SQLite 'Blob' size limits (which is currently
2GiB). So if you have asset files larger than 2GiB, you'll have to split it
into multiple files.

------
profalseidol
The comparison on GPL vs BSD is henious. The only disadvantage is that you
lose the opportunity to be selfish.

------
fche
The comparison lacks a big item: distributed-ness: the whole git-remote push &
pull symmetry. It allows not only offline bare-minimum operation, but full
offline development, then later online merging. I don't see any signs that
fossil can do the same.

The comparison re. licenses is factually mistaken in several ways, but that's
probably not worth a great deal of discussion - it's too religious a topic.

~~~
eesmith
Most comparisons points out the major differences, rather than all the ways
they are the same.

As you can see from bullet point #5 from the fossil home page, it works
offline:

> CGI/SCGI Enabled - No server is required, but if you want to set one up,
> Fossil supports four easy server configurations.

and #6 concerns later online merging:

> Autosync - Fossil supports "autosync" mode which helps to keep projects
> moving forward by reducing the amount of needless forking and merging often
> associated with distributed projects.

There's also the quick start guide with an overview of distributed-ness -
[https://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki](https://fossil-
scm.org/fossil/doc/trunk/www/quickstart.wiki) .

------
vkaku
Some of those features are not features.

------
miguelmota
That comparison table made me dislike fossil even more. Fossil took something
that’s not broken, and broke it.

~~~
rwbt
I disagree. I would suggest you to atleast research it more before coming to
such strong conclusions.

~~~
miguelmota
You're right; did more research and it makes more sense considering the
problem niche it's solving. I jumped to assumptions too soon.

------
based2
ldap [https://www.fossil-scm.org/xfer/tktview/ec667f74f8](https://www.fossil-
scm.org/xfer/tktview/ec667f74f8)

------
fishdaemon
svn again?

------
fxfan
I'm surprised git caught on despite mercurial being much superior (hadn't
heard of fossil before). Git has the following shortcomings which are major
(some shared by other VCS too)

1) UI- terrible, terrible UI

2) Unncessarily complex data model

3) Doesn't scale well to large repos (until Microsoft's VFS- windows only)

(and many others...)

~~~
rkangel
Git won over Mercurial simply due to Github. There were some other minor
contributing factors - association with Linus, speed - but they are
insignificant compared to how popular Gihub was (for good reason) and
therefore how many people were exposed to git.

The Mercurial alternatives like bitbucket just didn't have the same spread,
and we got stuck with year after year of teaching new people a difficult
interface.

~~~
georgyo
Git won the war before GitHub existed. More projects were switching to git
than hg.

GitHub was then mirroring open source projects git repos without asking.
(Which I think is fine, but ruffled some feathers back then)

GitHub could have easily been hghub, but they targeted git because it was
already winning.

~~~
pseudalopex
Git was more popular for C, Perl, and Ruby. Mercurial was more popular for
Java and Python. It was far ahead on Windows. Google and Atlassian bet on
Mercurial well after GitHub existed. The idea that only one could win would
have been strange to a lot of people at the time.

