1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<title>Fossil Versus Git</title>
<h2>1.0 Don't Stress!</h2>
If you start out using one DVCS and later decide you like the other better,
it is [./inout.wiki | easy to change].
But it also helps to be informed about the differences between
[http://git-scm.com | Git] and Fossil. 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.
<h2>2.0 Executive Summary:</h2>
<blockquote><center><table border=1 cellpadding=5>
|
|
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<title>Fossil Versus Git</title>
<h2>1.0 Don't Stress!</h2>
If you start out using one DVCS and later decide you like the other better,
it is [./inout.wiki | easy to change].
But it also helps to be informed about the differences between
[http://git-scm.com | Git] and Fossil. 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.
<h2>2.0 Executive Summary:</h2>
<blockquote><center><table border=1 cellpadding=5>
|
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
"[https://github.com/ | github]-in-a-box".
<h3>3.2 Sharding versus Replicating</h3>
Git makes it easy for each repository in a project to hold a subset of
the branches for that project. In fact, it is entirely possible and not
uncommon for no repository in the project to hold all the different code
versions for a project. Instead the information is distributed.
Individual developers have one or more private branches. A hierarchy
of integrators merge changes from individual developers into collaborative
branches, until all the changes are merged together at the top-level master
branch. And all of this can be accomplished without having to have all the
code in any one repository. Developers or groups of developers can share
only those branches that they want to share and keep other branchs of the
project private. This is analogous to sharding an a distributed database.
Fossil allows private branches, but its default mode is to share everything.
And so in a Fossil project, all respositories tend to contain all of the
content at all times. This is analogous to replication in a
distributed database.
The Git model works best for large projects, like the
Linux kernel for which Git was designed.
Linus Torvalds does not need or want to see a thousand
different branches, one for each contributor. Git allows intermediary
"gate-keepers" to merge changes from multiple lower-level developers
into a single branch and only present Linus with a handful of branches
at a time. Git encourages a programming model where each developer
works in his or her own branch and then merges changes up the hierarchy
until they reach the master branch.
Fossil is designed for smaller and non-hierarchical teams where all
developers are operating directly on the master branch, or at most
a small number of well defined branches.
The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy
for multiple developers to work on a single branch and maintain
linear development on that branch and avoid needless forking
and merging.
<h3>3.3 Branches</h3>
Git (and especially GitHub) encourages a workflow where each developer
has his or her own branch or branches. Developers then send "pull requests"
to have their changes be merged into "official" branches by integrators.
For example, the Linux kernel team has a hierarchy of integrators with
Linus Torvalds at the root. Individual developers each have their own
private branches of the source tree into which they make their own changes.
They then encourage first-tier integrators to pull those changes. The
first-tier integrators merge together changes from multiple contributors
then try to get second-tier integrators to pull their branches. The
changes merge up the hierarchy until (hopefully) they are pulled into
"Linus's branch", at which time they become part of the "official" Linux.
In Git, each branch is "owned" by the person who creates it and works
on it. The owner might pull changes from others, but the owner is always
in control of the branch. Branches are developer-centric.
Fossil, on the other hand, encourages a workflow where branches are
associated with features or releases, not individual developers.
All developers share all branches in common, and two
or more developers can and often do intersperse commits onto the same branch.
Branches do not belong to individuals. All branches are read/write
accessible to all developers at all times. There is no need
for integrators to merge together changes from various independent
developers. Instead, all of the developers work together cooperatively
and the changes stay integrated naturally.
So to a first approximation, branches in Git are developer-centric whereas
branches in Fossil are feature-centric.
The Git approach scales much better for large projects like the Linux
kernel with thousands of contributors who in many cases don't even know
each others names. The integrators serve a gatekeeper role to help keep
undesirable code out of the official Linux source tree. On the other hand,
not many projects are as big or as loosely organized as the Linux kernel.
Most projects have a small team of developers who all know each other
well and trust each other, and who enjoy working together collaboratively
without the overhead and hierarchy of integrators.
One consequence of the "everybody-sees-everything" focus of Fossil is that
branch names are global and are part of the distributed and synchronized
|
|
|
|
|
|
|
|
|
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
"[https://github.com/ | github]-in-a-box".
<h3>3.2 Sharding versus Replicating</h3>
Git makes it easy for each repository in a project to hold a subset of
the branches for that project. In fact, it is entirely possible and not
uncommon for no repository in the project to hold all the different code
versions for a project. Instead the information is distributed.
Individual developers have one or more private branches. A hierarchy
of integrators merge changes from individual developers into collaborative
branches, until all the changes are merged together at the top-level master
branch. And all of this can be accomplished without having to have all the
code in any one repository. Developers or groups of developers can share
only those branches that they want to share and keep other branchs of the
project private. This is analogous to sharding an a distributed database.
Fossil allows private branches, but its default mode is to share everything.
And so in a Fossil project, all repositories tend to contain all of the
content at all times. This is analogous to replication in a
distributed database.
The Git model works best for large projects, like the
Linux kernel for which Git was designed.
Linus Torvalds does not need or want to see a thousand
different branches, one for each contributor. Git allows intermediary
"gate-keepers" to merge changes from multiple lower-level developers
into a single branch and only present Linus with a handful of branches
at a time. Git encourages a programming model where each developer
works in his or her own branch and then merges changes up the hierarchy
until they reach the master branch.
Fossil is designed for smaller and non-hierarchical teams where all
developers are operating directly on the master branch, or at most
a small number of well defined branches.
The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy
for multiple developers to work on a single branch and maintain
linear development on that branch and avoid needless forking
and merging.
<h3>3.3 Branches</h3>
Git (and especially GitHub) encourages a workflow where each developer
has his or her own branch or branches. Developers then send "pull requests"
to have their changes be merged into "official" branches by integrators.
For example, the Linux kernel team has a hierarchy of integrators with
Linus Torvalds at the root. Individual developers each have their own
private branches of the source tree into which they make their own changes.
They then encourage first-tier integrators to pull those changes. The
first-tier integrators merge together changes from multiple contributors
then try to get second-tier integrators to pull their branches. The
changes merge up the hierarchy until (hopefully) they are pulled into
"Linus's branch", at which time they become part of the "official" Linux.
In Git, each branch is "owned" by the person who creates it and works
on it. The owner might pull changes from others, but the owner is always
in control of the branch. Branches are developer-centric.
Fossil, on the other hand, encourages a workflow where branches are
associated with features or releases, not individual developers.
All developers share all branches in common, and two
or more developers can and often do intersperse commits onto the same branch.
Branches do not belong to individuals. All branches are read/write
accessible to all developers at all times. There is no need
for integrators to merge together changes from various independent
developers. Instead, all of the developers work together cooperatively
and the changes stay integrated naturally.
So to a first approximation, branches in Git are developer-centric whereas
branches in Fossil are feature-centric.
The Git approach scales much better for large projects like the Linux
kernel with thousands of contributors who in many cases don't even know
each others names. The integrators serve a gatekeeper role to help keep
undesirable code out of the official Linux source tree. On the other hand,
not many projects are as big or as loosely organized as the Linux kernel.
Most projects have a small team of developers who all know each other
well and trust each other, and who enjoy working together collaboratively
without the overhead and hierarchy of integrators.
One consequence of the "everybody-sees-everything" focus of Fossil is that
branch names are global and are part of the distributed and synchronized
|
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
development. One should not have to stop and think about how to operate
the VCS. Of course, no VCS is ideal. Every VCS requires the developer
to think about version control to some extent. But one wants to minimize
the thinking about version control.
Git requires the developer to maintain a more complex mental model than
most other DVCSes. Git takes longer to learn. And you have to spend
more time thinking about what you are doing with Git.
Fossil strives for simplicity. Fossil wants to be easy to learn and to
require little thinking about how to operating it.
[./quotes.wiki | Reports from the field]
indicate that Fossil is mostly successful at this effort.
<h3>3.5 Web Interface</h3>
Git has a web interface, but it requires a fair amount of setup and an
external web server. Fossil comes with a fully functional
|
|
|
|
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
development. One should not have to stop and think about how to operate
the VCS. Of course, no VCS is ideal. Every VCS requires the developer
to think about version control to some extent. But one wants to minimize
the thinking about version control.
Git requires the developer to maintain a more complex mental model than
most other DVCSes. Git takes longer to learn. And you have to spend
more time thinking about what you are doing with Git.
Fossil strives for simplicity. Fossil wants to be easy to learn and to
require little thinking about how to operating it.
[./quotes.wiki | Reports from the field]
indicate that Fossil is mostly successful at this effort.
<h3>3.5 Web Interface</h3>
Git has a web interface, but it requires a fair amount of setup and an
external web server. Fossil comes with a fully functional
|
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
|
<h3>3.8 Audit Trail</h3>
Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository. Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand. This is important if you view the history of a project
as part of the documentation for the project.
Fossil takes an opposing view. Fossil views history as sacrosanct and
stubornly refuses to change it.
Fossil allows mistakes to be corrected (for example, check-in comments
can be revised, and check-ins can be moved onto new branches even after
the check-in has occurred) but the correction is an addition to the respository
and the original actions are preserved and displayed alongside
the corrections, thus preserving an historically accurate audit trail.
This is analogous to an accountant marking through an incorrect
entry in a ledger and writing in a correction beside it, rather than
erasing and incorrect entry.
To put it another way, Git remembers what you should have done whereas
Fossil remembers what you actually did.
The lack of a "rebase" command and the inability to rewrite history
is considered a feature of Fossil, not an omission or bug.
<h3>3.9 License</h3>
Both Git and Fossil are open-source. Git is under
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users. However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.
|
|
|
|
|
|
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
|
<h3>3.8 Audit Trail</h3>
Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository. Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand. This is important if you view the history of a project
as part of the documentation for the project.
Fossil takes an opposing view. Fossil views history as sacrosanct and
stubornly refuses to change it.
Fossil allows mistakes to be corrected (for example, check-in comments
can be revised, and check-ins can be moved onto new branches even after
the check-in has occurred) but the correction is an addition to the repository
and the original actions are preserved and displayed alongside
the corrections, thus preserving an historically accurate audit trail.
This is analogous to an accountant marking through an incorrect
entry in a ledger and writing in a correction beside it, rather than
erasing and incorrect entry.
To put it another way, Git remembers what you should have done whereas
Fossil remembers what you actually did.
The lack of a "rebase" command and the inability to rewrite history
is considered a feature of Fossil, not an omission or bug.
<h3>3.9 License</h3>
Both Git and Fossil are open-source. Git is under
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users. However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.
|