Fossil

Changes On Branch bsd-vs-gpl
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Changes In Branch bsd-vs-gpl Excluding Merge-Ins

This is equivalent to a diff from 69e7827d26 to a52e68459f

2019-07-17
02:37
Reworked several sections of the fossil-v-git.wiki doc as sub-sections of "Linux vs. SQLite", which now acts as a frame for those sections. Some of these sections are expanded while others disappear entirely, most especially the "BSD vs GPL" argument that we started off on the now-merged branch to try and refine. We replace a discussion of licensing with one of community structure and our approach to patch acceptance, which is more of what the old licensing discussion was trying to get at without getting into the details of software licensing per se. ... (check-in: 69ec89b591 user: wyoung tags: trunk)
2019-07-16
15:44
Reduced redundancy in the new feature set size vs ease of use discussion in fossil-v-git. ... (Closed-Leaf check-in: a52e68459f user: wyoung tags: bsd-vs-gpl)
15:05
Rewrote the "Accepting Contributions" section of the fossil-v-git doc to focus on the size of each tool in terms of SLOC and features, rather than on licensing details. ... (check-in: 5fe84e7011 user: wyoung tags: bsd-vs-gpl)
2019-07-12
13:58
Improved error messages when a commit fails due to a lock conflict: Show the age of the lock in addition to the user. Suggest using the new --override-lock option instead of --allow-fork. Expire locks after any successful check-in from the same check-out. ... (check-in: 3a5caa86db user: drh tags: trunk)
13:25
Merged in Linux vs SQLite stuff from trunk ... (check-in: f5321731f9 user: wyoung tags: bsd-vs-gpl)
13:24
Clarified the scale of the Linux vs SQLite projects in the same-named section of the Git vs Fossil doc, tightened up the discussion a bit, and added hard SLOC stats to ground it all. Most controversially, added the rattle wrench analogy. ... (check-in: 69e7827d26 user: wyoung tags: trunk)
12:37
Fix a typo in the fossil-v-git.wiki document, as reported on the forum. "fossil all status" should be "fossil all changes". ... (check-in: 9b51c42a8b user: drh tags: trunk)

Changes to www/fossil-v-git.wiki.

32
33
34
35
36
37
38


39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
<tr><td>File versioning only</td>
    <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
<tr><td>Ad-hoc pile-of-files key/value database</td>
    <td>Relational SQL database</td></tr>
<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
<tr><td>Designed for Linux kernel development</td>
    <td>Designed for SQLite development</td></tr>


<tr><td>Focus on individual branches</td>
    <td>Focus on the entire tree of changes</td></tr>
<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
<tr><td>One check-out per repository</td>
    <td>Many check-outs per repository</td></tr>
<tr><td>Remembers what you should have done</td>
    <td>Remembers what you actually did</td></tr>
<tr><td>GPL</td><td>BSD</td></tr>
</table></blockquote>

<h3>2.1 Feature Set</h3>

Git provides file versioning services only, whereas Fossil adds
integrated [./wikitheory.wiki | wiki],
[./bugtheory.wiki | ticketing &amp; bug tracking],
[./embeddeddoc.wiki | embedded documentation], 
[./event.wiki | technical notes], and a [./forum.wiki | forum].
These additional capabilities are available for Git as 3rd-party







>
>







<


|







32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

48
49
50
51
52
53
54
55
56
57
<tr><td>File versioning only</td>
    <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
<tr><td>Ad-hoc pile-of-files key/value database</td>
    <td>Relational SQL database</td></tr>
<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
<tr><td>Designed for Linux kernel development</td>
    <td>Designed for SQLite development</td></tr>
<tr><td>Many contributors</td>
    <td>Select contributors</td></tr>
<tr><td>Focus on individual branches</td>
    <td>Focus on the entire tree of changes</td></tr>
<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
<tr><td>One check-out per repository</td>
    <td>Many check-outs per repository</td></tr>
<tr><td>Remembers what you should have done</td>
    <td>Remembers what you actually did</td></tr>

</table></blockquote>

<h3 id="features">2.1 Feature Set</h3>

Git provides file versioning services only, whereas Fossil adds
integrated [./wikitheory.wiki | wiki],
[./bugtheory.wiki | ticketing &amp; bug tracking],
[./embeddeddoc.wiki | embedded documentation], 
[./event.wiki | technical notes], and a [./forum.wiki | forum].
These additional capabilities are available for Git as 3rd-party
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script]
suffice to instantiate a full-featured developer website.  To accomplish
the same using Git requires locating, installing, configuring, integrating,
and managing a wide assortment of separate tools.  Standing up a developer
website using Fossil can be done in minutes, whereas doing the same using
Git requires hours or days.

<h3>2.2 Database</h3>

The baseline data structures for Fossil and Git are the same, modulo
formatting details.  Both systems store check-ins as immutable
objects referencing their immediate ancestors and named by a
cryptographic hash of the check-in content.

The difference is that Git stores its objects as individual files







|







71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script]
suffice to instantiate a full-featured developer website.  To accomplish
the same using Git requires locating, installing, configuring, integrating,
and managing a wide assortment of separate tools.  Standing up a developer
website using Fossil can be done in minutes, whereas doing the same using
Git requires hours or days.

<h3 id="database">2.2 Database</h3>

The baseline data structures for Fossil and Git are the same, modulo
formatting details.  Both systems store check-ins as immutable
objects referencing their immediate ancestors and named by a
cryptographic hash of the check-in content.

The difference is that Git stores its objects as individual files
114
115
116
117
118
119
120
121

122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161


















162

163












164


165



166



167









168

169







170

























171










172
















173
174
175













176





177









178





179











180




181



182
183
184
185
186
187
188
189
190
191
The ease with which check-ins can be located and queried in Fossil
has resulted in a huge variety of reports and status screens
([./webpage-ex.md|examples]) that show project state
in ways that help developers
maintain enhanced awareness and comprehension
and avoid errors.

<h3>2.3 Cathedral vs. Bazaar</h3>


Fossil and Git promote different development styles.  Git promotes a
"[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|bazaar]"
development style in which numerous anonymous developers make
small and sometimes haphazard contributions.  Fossil
promotes a "cathedral" development model in which the project is
closely supervised by an highly engaged architect and implemented by
a clique of developers.

Nota Bene:  This is not to say that Git cannot be used for cathedral-style
development or that Fossil cannot be used for bazaar-style development.
They can be.  But those modes are not their design intent nor their
low-friction path.

Git encourages a style in which individual developers work in relative
isolation, maintaining their
own branches and occasionally rebasing and pushing selected changes up
to the main repository.  Developers using Git often have their own
private branches that nobody else ever sees.  Work becomes siloed.
This is exactly what one wants when doing bazaar-style development.

Fossil, in contrast, strives to keep all changes from all contributors
mirrored in the main repository (in separate branches) at all times.
Work in progress from one developer is readily visible to all other
developers and to the project leader, well before the code is ready
to integrate.  Fossil places a lot of emphasis on reporting the state
of the project, and the changes underway by all developers, so that
all developers and especially the project leader can maintain a better
mental picture of what is happening, and better situational awareness.

<h3>2.4 Linux vs. SQLite</h3>

Git was specifically designed to support the development of the Linux kernel.
Fossil was specifically designed to support the development of SQLite.

SQLite is much more widely deployed than the Linux kernel, but for
Linux-based systems, the kernel is the more fundamental component.
Although both projects must rank high on any objective list of "most
important FOSS projects," the two projects are almost entirely unlike
one another, and this shows up in the design choices of the tools


















created to support them.














The Linux kernel uses a bazaar-style development model.  There are thousands and


thousands of contributors, most of whom do not know each others names.



These thousands are responsible for producing roughly 89⨉ more code than



is in SQLite. (10.7









[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC

according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is







designed for this scenario.




































SQLite uses cathedral-style development.  95% of the code in SQLite
















comes from just four programmers, and 64% of it is from the lead developer alone.
The SQLite developers know each other well and interact daily.
Fossil is designed for this development model.



















We think you should ask yourself whether you have









[https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale





software configuration management problems or











[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale




problems when choosing your DVCS. You don't use a pneumatic ratchet



wrench to hang a picture on the living room wall.

<h3>2.5 Individual Branches vs. The Entire Change History</h3>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.

For example, the default "sync" behavior in Git is to only sync
a single branch, whereas with Fossil the only sync option it to







|
>

|
<
<
<
<
<
<
|
<
<
<
<
|
<
<
<
<
<
<
|
<
<
<
<
<
<
<
<
|
<
|
<
|
<


|
|
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
>

>
>
>
>
>
>
>
>
>
>
>
>
|
>
>
|
>
>
>
|
>
>
>
|
>
>
>
>
>
>
>
>
>
|
>
|
>
>
>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
|
>
>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
|
>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
>
>
|
>
>
>
>
|
>
>
>
|

|







115
116
117
118
119
120
121
122
123
124
125






126




127






128








129

130

131

132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
The ease with which check-ins can be located and queried in Fossil
has resulted in a huge variety of reports and status screens
([./webpage-ex.md|examples]) that show project state
in ways that help developers
maintain enhanced awareness and comprehension
and avoid errors.


<h3 id="vs-linux">2.3 Linux vs. SQLite</h3>

Fossil and Git promote different development styles because each one was






specifically designed to support the primary authors' main software




development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus






Torvalds] designed Git to support development of








[https://www.kernel.org/|the Linux kernel], and

[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] designed

Fossil to support the development of [https://sqlite.org/|SQLite].

SQLite is much more widely deployed than the Linux kernel, but for
Linux-based systems, the kernel is the more fundamental component.
Both projects must rank high on any objective list of "most
important FOSS projects," yet these two projects are almost entirely unlike
one another.

In the following sections, we will explain how three key differences
between Linux and SQLite dictated the design of each DVCS's low-friction
usage path.

When deciding between these two DVCSes, you should ask yourself, "Is my
project more like Linux or more like SQLite?"


<h4 id="devorg">2.3.1 Development Organization</h4>

Eric S. Raymond's seminal essay-turned-book
"[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
Cathedral and the Bazaar]" details the two major development
organization styles found in
[https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS]
projects. As it happens, Linux and SQLite fall on opposite sides of this
dichotomy. Differing development organization styles dictate a different
design and low-friction usage path in the tools created to support each
project.

Git promotes the Linux kernel's bazaar development style, in which a
loosely-associated mass of developers contribute their work through
[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|a
hierarchy of lieutenants] who manage and clean up these contributions
for consideration by Linus Torvalds, who has the power to cherrypick
individual contributions into his version of the Linux kernel. Git
allows an anonymous developer to rebase and push specific locally-named
private branches, so that a Git repo clone often isn't really a clone at
all: it may have an arbitrary number of differences relative to the
repository it originally cloned from. Git encourages siloed development.
Select work in a developer's local repository may remain private
indefinitely.

All of this is exactly what one wants when doing bazaar-style
development.

Fossil's normal mode of operation differs on every one of these points,
with the specific designed-in goal of promoting SQLite's cathedral
development model:

<ul>
    <li><p><b>Personal engagement:</b> SQLite's developers know each
    other by name and work together daily on the project.</p></li>

    <li><p><b>Trust over hierarchy:</b> Fossil supports developers given
    direct commit capability on the repository rather than support a
    hierarchical "dictator and lieutenants" contribution style.  D.
    Richard Hipp rarely overrides decisions made by those he has trusted
    with commit access on his repositories.
    [/doc/trunk/www/admin-v-setup.md|Some users] have more power over
    what they can do with the repository, but Fossil does not otherwise
    directly support the enforcement of a development organization's
    social hierarchy. Fossil is a great fit for
    [https://en.wikipedia.org/wiki/Flat_organization|flat
    organizations].</p></li>

    <li><p><b>Anonymous contribution discouraged:</b> Anonymous
    contribution is possible in a Fossil project, but there is no
    low-friction path to it, as in Git. Fossil's closest equivalent to
    Git pull requests is the [/help?cmd=bundle|bundle], which requires
    higher engagement than firing off a PR. Both Fossil and Git also
    support <tt>patch(1)</tt> files, but that's a lossy contribution
    path in both systems.</p></li>

    <li><p><b>No rebasing:</b> When a remote clone syncs changes up to
    its parent repository, the changes are sent exactly as they were
    committed to the local repository. [#history|There is no rebasing
    mechanism, on purpose.]</p></li>

    <li><p><b>Sync over push:</b> Explicit pushes are uncommon in
    Fossil-based projects; the default is to rely on
    [/help?cmd=autosync|autosync mode] instead, in which each commit
    normally syncs immediately to its parent repository, so that
    explicit pushes are not needed.</p></li>

    <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not
    purely local labels. They sync along with everything else, so
    everyone everyone sees the same set of branch names.</p></li>

    <li><p><b>Private branches are rare:</b>
    [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but
    they're normally used to handle rare exception cases, whereas in
    many Git projects, they're part of the straight-line development
    process.</p></li>

    <li><p><b>Identical clones:</b> Fossil's autosync system tries to
    keep local clones identical to the repository it cloned
    from.</p></li>
</ul>

Where Git encourages siloed development, Fossil fights against it.
[https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put
it well in his book on software project management,
[https://www.amazon.com/dp/0735623198/|Dynamics of Software
Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a
guy in a room]." Fossil places a lot of emphasis on synchronizing
everyone's work and on reporting on the state of the project and the
work of its developers, so that everyone — especially the project leader
— can maintain a better mental picture of what is happening, leading to
better situational awareness.

Each DVCS can be used in the opposite style, but doing so works against
their low-friction paths.


<h4 id="scale">2.3.2 Scale</h4>

The Linux kernel has a far bigger developer community than that of
SQLite: there are thousands and thousands of contributors to Linux, most
of whom do not know each others names. These thousands are responsible
for producing roughly 89⨉ more code than is in SQLite. (10.7
[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC
according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux
kernel and its development process were already uncommonly large back in
2005 when Git was designed, specifically to support the consequences of
having such a large set of developers working on such a large code base.

95% of the code in SQLite comes from just four programmers, and 64% of
it is from the lead developer alone. The SQLite developers know each
other well and interact daily. Fossil was designed for this development
model. As well, we think the fact of Fossil's birth a year later
than Git allowed it to learn from some of the key design mistakes in
Git.

We think you should ask yourself whether you have Linus Torvalds scale
software configuration management problems or D. Richard Hipp scale
problems when choosing your DVCS. An
[https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
not the best way to hang a picture on the living room wall.


<h4 id="contrib">2.3.3 Accepting Contributions</h4>

As of this writing, Git has received about 4.5⨉ as many commits as
Fossil resulting in about 2.5⨉ as many lines of source code. The line
count excludes tests and in-tree third-party dependencies. It does not
exclude the default GUI for each, since it's integral for Fossil, so we
count the size of <tt>gitk</tt> in this.

It is obvious that Git is bigger in part because of its first-mover
advantage, which resulted in a larger user community, which results in
more contributions. But is that the <i>only</i> reason? We believe there
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 size 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.

Most DVCS users are not using a DVCS for its own sake, so we do not want
the DVCS with the most features, we want the one with a more easily
internalized behavior set, which we can pick up, use quickly, and then
set aside in order to get back to our
actual job as quickly as possible. There is some minimal set of features
required to achieve that, but there is a level beyond which more
features only slow us down while we're learning about the DVCS, as 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, you make the tool <i>less</i> productive to use.

We achieve this 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.

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.


<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.

For example, the default "sync" behavior in Git is to only sync
a single branch, whereas with Fossil the only sync option it to
205
206
207
208
209
210
211

212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229

230
231
232
233
234
235
236
237
by every contributor to Linux, as such extreme visibility does not scale
well.  But Fossil was written for the cathedral-style SQLite project
with just a handful of active committers.  Seeing all
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more 
tightly focused and cohesive implementation.


<h3>2.6 Lots of little tools vs. Self-contained system</h3>

Git consists of many small tools, each doing one small part of the job,
which can be recombined (by experts) to perform powerful operations.
Git has a lot of complexity and many dependencies and requires an "installer"
script or program to get it running.

Fossil is a single self-contained stand-alone executable with hardly
any dependencies.  Fossil can be (and often is) run inside a
minimally configured chroot jail.  To install Fossil,
one merely puts the executable somewhere in the $PATH.

The designer of Git says that the Unix philosophy is to have lots of
small tools that collaborate to get the job done.  The designer of
Fossil says that the Unix philosophy is "It just works."  Both
individuals have written their DVCSes to reflect their own view
of the "Unix philosophy."


<h3>2.7 One vs. Many Check-outs per Repository</h3>

A "repository" in Git is a pile-of-files in the ".git" subdirectory
of a single check-out.  The check-out and the repository are located
together in the filesystem.

With Fossil, a "repository" is a single SQLite database file
that can be stored anywhere.  There







>
|

















>
|







337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
by every contributor to Linux, as such extreme visibility does not scale
well.  But Fossil was written for the cathedral-style SQLite project
with just a handful of active committers.  Seeing all
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more 
tightly focused and cohesive implementation.


<h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3>

Git consists of many small tools, each doing one small part of the job,
which can be recombined (by experts) to perform powerful operations.
Git has a lot of complexity and many dependencies and requires an "installer"
script or program to get it running.

Fossil is a single self-contained stand-alone executable with hardly
any dependencies.  Fossil can be (and often is) run inside a
minimally configured chroot jail.  To install Fossil,
one merely puts the executable somewhere in the $PATH.

The designer of Git says that the Unix philosophy is to have lots of
small tools that collaborate to get the job done.  The designer of
Fossil says that the Unix philosophy is "It just works."  Both
individuals have written their DVCSes to reflect their own view
of the "Unix philosophy."


<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>

A "repository" in Git is a pile-of-files in the ".git" subdirectory
of a single check-out.  The check-out and the repository are located
together in the filesystem.

With Fossil, a "repository" is a single SQLite database file
that can be stored anywhere.  There
254
255
256
257
258
259
260

261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329

330
331
332
333
334
335
336
337
With Fossil, the complete decoupling of repository and check-out tree
means every working check-out tree is treated equally. It's common in
Fossil to have a check-out tree for each major working branch so that
you can switch branches with a "cd" command rather than replace the
current working file set with a different file set by updating in place,
as Git prefers.


<h3>2.8 What you should have done vs. What you actually did</h3>

Git puts a lot of emphasis on maintaining
a "clean" check-in history.  Extraneous and experimental branches by
individual developers often never make it into the main repository.  And
branches are often rebased before being pushed, to make
it appear as if development had been linear.  Git strives to record what
the development of a project should have looked like had there been no
mistakes.

Fossil, in contrast, puts more emphasis on recording exactly what happened,
including all of the messy errors, dead-ends, experimental branches, and
so forth.  One might argue that this
makes the history of a Fossil project "messy."  But another point of view
is that this makes the history "accurate."  In actual practice, the
superior reporting tools available in Fossil mean that the added "mess"
is not a factor.

One commentator has mused that Git records history according to
the victors, whereas Fossil records history as it actually happened.

<h3>2.9 GPL vs. BSD</h3>

Git is covered by the GPL license whereas Fossil is covered by
[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD
style license].

Consider the difference between GPL and BSD licenses:  GPL is designed
to make writing easier at the expense of making reading harder.  BSD is
designed to make reading easier at the expense of making writing harder.

To a first approximation, the GPL license grants the right to read
source code to anyone who promises to give back enhancements.  In other
words, the act of reading GPL source code (a prerequiste for making changes)
implies acceptance of the license which requires updates to be contributed
back under the same license.  (The details are more complex, but the
foregoing captures the essence of the idea.)  A big advantage of the GPL
is that anybody can contribute to the code without having to sign additional
legal documentation because they have implied their acceptance of the GPL
license by the very act of reading the source code.  This means that a GPL
project can legally accept anonymous and drive-by patches.

The BSD licenses, on the other hand, make reading much easier than the GPL,
because the reader need not surrender proprietary interest
in their own enhancements.  On the flip side, BSD and similarly licensed
projects must obtain legal affidavits from authors before
new content can be added into the project.  Anonymous and drive-by
patches cannot be accepted.  This makes signing up new contributors for
BSD licensed projects harder.

The licenses on the implementations of Git and Fossil only apply to the
implementations themselves, not to the projects which the systems store.
Nevertheless, one can see a more GPL-oriented world-view in Git and a
more BSD-oriented world-view in Fossil.  Git encourages anonymous contributions
and siloed development, which are hallmarks of the GPL/bazaar approach to
software, whereas Fossil encourages a more tightly collaborative,
cliquish, cathedral-style approach more typical of BSD-licensed projects.

<h2>3.0 Missing Features</h2>

Most of the capabilities found in Git are also available in Fossil and
the other way around. For example, both systems have local check-outs,
remote repositories, push/pull/sync, bisect capabilities, and a "stash."
Both systems store project history as a directed acyclic graph (DAG)
of immutable check-in objects.

But there are a few capabilities in one system that are missing from the
other.


<h3>3.1 Features found in Fossil but missing from Git</h3>

  *  <b>The ability to show descendents of a check-in.</b>

   Both Git and Fossil can easily find the ancestors of a check-in.  But
   only Fossil shows the descendents.  (It is possible to find the
   descendents of a check-in in Git using the log, but that is sufficiently
   difficult that nobody ever actually does it.)







>
|




















<

<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
|










>
|







388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416

417



































418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
With Fossil, the complete decoupling of repository and check-out tree
means every working check-out tree is treated equally. It's common in
Fossil to have a check-out tree for each major working branch so that
you can switch branches with a "cd" command rather than replace the
current working file set with a different file set by updating in place,
as Git prefers.


<h3 id="history">2.7 What you should have done vs. What you actually did</h3>

Git puts a lot of emphasis on maintaining
a "clean" check-in history.  Extraneous and experimental branches by
individual developers often never make it into the main repository.  And
branches are often rebased before being pushed, to make
it appear as if development had been linear.  Git strives to record what
the development of a project should have looked like had there been no
mistakes.

Fossil, in contrast, puts more emphasis on recording exactly what happened,
including all of the messy errors, dead-ends, experimental branches, and
so forth.  One might argue that this
makes the history of a Fossil project "messy."  But another point of view
is that this makes the history "accurate."  In actual practice, the
superior reporting tools available in Fossil mean that the added "mess"
is not a factor.

One commentator has mused that Git records history according to
the victors, whereas Fossil records history as it actually happened.






































<h2 id="missing">3.0 Missing Features</h2>

Most of the capabilities found in Git are also available in Fossil and
the other way around. For example, both systems have local check-outs,
remote repositories, push/pull/sync, bisect capabilities, and a "stash."
Both systems store project history as a directed acyclic graph (DAG)
of immutable check-in objects.

But there are a few capabilities in one system that are missing from the
other.


<h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3>

  *  <b>The ability to show descendents of a check-in.</b>

   Both Git and Fossil can easily find the ancestors of a check-in.  But
   only Fossil shows the descendents.  (It is possible to find the
   descendents of a check-in in Git using the log, but that is sufficiently
   difficult that nobody ever actually does it.)
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
  *  <b>The [/help?cmd=ui|fossil ui] command</b>

   Fossil supports an integrated web interface.  Some of the same features
   are available using third-party add-ons for Git, but they do not provide
   nearly as many features and they are not nearly as convenient to use.


<h3>3.2 Features found in Git but missing from Fossil</h3>

  *  <b>Rebase</b>

   Because of its emphasis on recording history exactly as it happened,
   rather than as we would have liked it to happen, Fossil deliberately
   does not provide a "rebase" command.  One can rebase manually in Fossil,
   with sufficient perserverence, but it is not something that can be done with







|







462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
  *  <b>The [/help?cmd=ui|fossil ui] command</b>

   Fossil supports an integrated web interface.  Some of the same features
   are available using third-party add-ons for Git, but they do not provide
   nearly as many features and they are not nearly as convenient to use.


<h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3>

  *  <b>Rebase</b>

   Because of its emphasis on recording history exactly as it happened,
   rather than as we would have liked it to happen, Fossil deliberately
   does not provide a "rebase" command.  One can rebase manually in Fossil,
   with sufficient perserverence, but it is not something that can be done with