Fossil

Check-in [5566c853]
Login

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

Overview
Comment:Fix typos in the fossil-v-git.wiki document.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 5566c8535ae3c0af98cf064bd3d370a197ba6867
User & Date: drh 2016-06-10 13:46:46
Context
2016-06-10
14:16
Updates to the change log. check-in: ecd3dc53 user: drh tags: trunk
13:46
Fix typos in the fossil-v-git.wiki document. check-in: 5566c853 user: drh tags: trunk
13:28
Add the "Special Features" subheading in the Markdown documentation. check-in: a6725ea5 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

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

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
..
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
..
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
...
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

<h2>1.0 Don't Stress!</h2>

If you start out using one DVCS and later decide you like the other better,
you can easily [./inout.wiki | move your content]&#185;.

Fossil and [http://git-scm.com | Git] are very similar in many respects,
but there are also important differences.
See the table below for
a high-level summary and the text that follows for more details.

Keep in mind that you are reading this on a Fossil website,
so the information here
might be biased in favor of Fossil.  Ask around with people who have
used both Fossil and Git for other opinions.
................................................................................
<tr><td>GPL</td><td>BSD</td></tr>
</table></center></blockquote>

<h2>3.0 Discussion</h2>

<h3>3.1 Feature Set</h3>

Git provides file versioning services only, whereas Fossil adds an
integrated [./wikitheory.wiki | wiki],
[./bugtheory.wiki | ticketing &amp; bug tracking],
[./embeddeddoc.wiki | embedded documentation], and
[./event.wiki | Technical notes].
These additional capabilities are available for Git as 3rd-party and/or
user-installed add-ons, but with Fossil they are integrated into
the design.  One way to describe Fossil is that it is
................................................................................
relational ([https://www.sqlite.org/|SQLite]) database file.  To put it
another way, Git uses an ad-hoc pile-of-files key/value database whereas
Fossil uses a proven, general-purpose SQL database.  This
difference is more than an implementation detail.  It
has important consequences.

With Git, one can easily locate the ancestors of a particular check-in
by following the pointers embedded the check-in object, but it is
difficult to go the other direction and locate the descendants of a
check-in.  It is so difficult, in fact, that neither native Git nor
GitHub provide this capability.  With Git, if you are looking at some
historical check-in then you cannot ask
"what came next" or "what are the children of this check-in".

Fossil, on the other hand, parses essential information about check-ins
................................................................................
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 the their
low-friction path.

Git encourages a style in which individual developers work in relative
isolation, maintaining their
own branches and the 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







|







 







|







 







|







 







|







2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
..
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
..
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
...
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

<h2>1.0 Don't Stress!</h2>

If you start out using one DVCS and later decide you like the other better,
you can easily [./inout.wiki | move your content]&#185;.

Fossil and [http://git-scm.com | Git] are very similar in many respects,
but they also have important differences.
See the table below for
a high-level summary and the text that follows for more details.

Keep in mind that you are reading this on a Fossil website,
so the information here
might be biased in favor of Fossil.  Ask around with people who have
used both Fossil and Git for other opinions.
................................................................................
<tr><td>GPL</td><td>BSD</td></tr>
</table></center></blockquote>

<h2>3.0 Discussion</h2>

<h3>3.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], and
[./event.wiki | Technical notes].
These additional capabilities are available for Git as 3rd-party and/or
user-installed add-ons, but with Fossil they are integrated into
the design.  One way to describe Fossil is that it is
................................................................................
relational ([https://www.sqlite.org/|SQLite]) database file.  To put it
another way, Git uses an ad-hoc pile-of-files key/value database whereas
Fossil uses a proven, general-purpose SQL database.  This
difference is more than an implementation detail.  It
has important consequences.

With Git, one can easily locate the ancestors of a particular check-in
by following the pointers embedded in the check-in object, but it is
difficult to go the other direction and locate the descendants of a
check-in.  It is so difficult, in fact, that neither native Git nor
GitHub provide this capability.  With Git, if you are looking at some
historical check-in then you cannot ask
"what came next" or "what are the children of this check-in".

Fossil, on the other hand, parses essential information about check-ins
................................................................................
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 the 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