Fossil

are other relevant differences that also play into this which fall out
of the "Linux vs. SQLite" framing: licensing, community structure, and
how we react to
[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
contributions]. In brief, it's harder to get a new feature into Fossil
than into Git.

A larger feature set is not necessarily a good thing. Git's command line
interface is famously arcane. Masters of the arcane are able to do
wizardly things, but only by studying their art deeply for years. This
strikes us as a good thing only in cases where use of the tool itself is
the primary point of that user's work.

Almost no one uses a DVCS for its own sake; very few people get paid
specifically in order to drive a DVCS. We use DVCSes as a tool to
support some other effort, so we do not necessarily want the DVCS with
the most features. We want a DVCS with easily internalized behavior so
we can thoroughly master it despite spending only a small fraction of
our working time thinking about the DVCS. We want to pick the tool up,
use it quickly, and then set it aside in order to get back to our actual
job as quickly as possible.

Professional software developers in particular are prone to focusing on
feature set sizes when choosing tools because this is sometimes a highly
important consideration. They spend all day, every day, in their
favorite text editors, and time they spend learning all of the arcana of
their favorite programming languages is well-spent. Skills with these
tools are direct productivity drivers, which in turn directly drives how
much money a developer can make. (Or how much idle time they can afford
to take, which amounts to the same thing.) But if you are a professional
software developer, we want you to ask yourself a question: "How do I
get paid more by mastering arcane features of my DVCS?" Unless you have
a good answer to that, you probably do not want to be choosing a DVCS
based on how many arcane features it has.

The argument is similar for other types of users: if you are a hobbyist,
how much time do you want to spend mastering your DVCSs instead of on
the hobby supported by use of that DVCS?

There is some minimal set of features required to achieve the purposes
that drive our selection of a DVCS, but there is a level beyond which
more features only slow us down while we're learning the tool, since we
must plow through documentation on features we're not likely to ever
use. When the number of features grows to the point where people of
normal motivation cannot spend the time to master them all, the tool
becomes <i>less</i> productive to use.

The core developers of the Fossil project achieve a balance between feature
set size and ease of use by
carefully choosing which users to give commit bits to, then in being
choosy about which of the contributed feature branches to merge down to
trunk. We say "no" to a lot of feature proposals.

The end result is that Fossil more closely adheres to
[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
principle of least astonishment] than Git does.


<h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4>