Fossil SCM
Assorted improvements to www/fossil-v-git.wiki: added hyperlinks, fixed some spelling, capitalization, and grammar problems, clarified "Linux" vs "Linux kernel", clarified the description of the git-worktree feature, moved punctuation inside double quotes (typography), and added a few detail paragraphs.
Commit
fd990128dd0dc00bf3a3d14febb7d65e2e958f9ca62cf5ff9e054c25e7529a7d
Parent
45199458839a5fb…
1 file changed
+59
-41
+59
-41
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | <title>Fossil Versus Git</title> |
| 2 | 2 | |
| 3 | 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | 4 | |
| 5 | 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | -you can easily [./inout.wiki | move your content]¹. | |
| 6 | +you can easily [./inout.wiki | move your content].¹ | |
| 7 | 7 | |
| 8 | 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | 9 | but they also have important differences. |
| 10 | 10 | See the table below for |
| 11 | 11 | a high-level summary and the text that follows for more details. |
| @@ -13,13 +13,16 @@ | ||
| 13 | 13 | Keep in mind that you are reading this on a Fossil website, and though |
| 14 | 14 | we try to be fair, the information here |
| 15 | 15 | might be biased in favor of Fossil. Ask around for second opinions from |
| 16 | 16 | people who have used <em>both</em> Fossil and Git. |
| 17 | 17 | |
| 18 | -¹<small><i>Git does not support | |
| 19 | -wiki, tickets, or tech-notes, so those elements will not transfer when | |
| 20 | -exporting from Fossil to Git.</i></small> | |
| 18 | +¹<small><i>Git does not include a | |
| 19 | +wiki, a ticket tracker, a forum, or a tech-note feature, so those elements will not transfer when | |
| 20 | +exporting from Fossil to Git. GitHub adds some of these to stock Git, | |
| 21 | +but because they're not part of Git proper, [./mirrortogithub.md|exporting a Fossil | |
| 22 | +repository to GitHub] will still not include them; Fossil tickets do not | |
| 23 | +become GitHub issues, for example.</i></small> | |
| 21 | 24 | |
| 22 | 25 | <h2>2.0 Differences Between Fossil And Git</h2> |
| 23 | 26 | |
| 24 | 27 | Differences between Fossil and Git are summarized by the following table, |
| 25 | 28 | with further description in the text that follows. |
| @@ -26,14 +29,14 @@ | ||
| 26 | 29 | |
| 27 | 30 | <blockquote><table border=1 cellpadding=5 align=center> |
| 28 | 31 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 29 | 32 | <tr><td>File versioning only</td> |
| 30 | 33 | <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> |
| 31 | -<tr><td>Ad-hoc, pile-of-files key/value database</td> | |
| 34 | +<tr><td>Ad-hoc pile-of-files key/value database</td> | |
| 32 | 35 | <td>Relational SQL database</td></tr> |
| 33 | 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 34 | -<tr><td>Designed for Linux development</td> | |
| 37 | +<tr><td>Designed for Linux kernel development</td> | |
| 35 | 38 | <td>Designed for SQLite development</td></tr> |
| 36 | 39 | <tr><td>Focus on individual branches</td> |
| 37 | 40 | <td>Focus on the entire tree of changes</td></tr> |
| 38 | 41 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 39 | 42 | <tr><td>One check-out per repository</td> |
| @@ -47,39 +50,42 @@ | ||
| 47 | 50 | |
| 48 | 51 | Git provides file versioning services only, whereas Fossil adds |
| 49 | 52 | integrated [./wikitheory.wiki | wiki], |
| 50 | 53 | [./bugtheory.wiki | ticketing & bug tracking], |
| 51 | 54 | [./embeddeddoc.wiki | embedded documentation], |
| 52 | -[./event.wiki | Technical notes], and a [./forum.wiki | forum]. | |
| 53 | -These additional capabilities are available for Git as 3rd-party and/or | |
| 54 | -user-installed add-ons, but with Fossil they are integrated into | |
| 55 | +[./event.wiki | technical notes], and a [./forum.wiki | forum]. | |
| 56 | +These additional capabilities are available for Git as 3rd-party | |
| 57 | +add-ons, but with Fossil they are integrated into | |
| 55 | 58 | the design. One way to describe Fossil is that it is |
| 56 | -"[https://github.com/ | github]-in-a-box". | |
| 59 | +"[https://github.com/ | GitHub]-in-a-box." | |
| 57 | 60 | |
| 58 | -If you clone Git's self-hosting repository you get just Git's source code. | |
| 61 | +If you clone [https://github.com/git/git|Git's self-hosting repository], | |
| 62 | +you get just Git's source code. | |
| 59 | 63 | If you clone Fossil's self-hosting repository, you get the entire |
| 60 | -Fossil website - source code, documentation, ticket history, and so forth. | |
| 64 | +Fossil website — source code, documentation, ticket history, and so forth. | |
| 65 | +That means you get a copy of this very article and all of its historical | |
| 66 | +versions, plus the same for all of the other public content on this site. | |
| 61 | 67 | |
| 62 | 68 | For developers who choose to self-host projects (rather than using a |
| 63 | 69 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 64 | -the stand-alone Fossil executable together with a 2-line CGI script | |
| 70 | +the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script] | |
| 65 | 71 | suffice to instantiate a full-featured developer website. To accomplish |
| 66 | 72 | the same using Git requires locating, installing, configuring, integrating, |
| 67 | 73 | and managing a wide assortment of separate tools. Standing up a developer |
| 68 | 74 | website using Fossil can be done in minutes, whereas doing the same using |
| 69 | 75 | Git requires hours or days. |
| 70 | 76 | |
| 71 | 77 | <h3>2.2 Database</h3> |
| 72 | 78 | |
| 73 | -The baseline data structures for Fossil and Git are the same (modulo | |
| 74 | -formatting details). Both systems store check-ins as immutable | |
| 79 | +The baseline data structures for Fossil and Git are the same, modulo | |
| 80 | +formatting details. Both systems store check-ins as immutable | |
| 75 | 81 | objects referencing their immediate ancestors and named by a |
| 76 | 82 | cryptographic hash of the check-in content. |
| 77 | 83 | |
| 78 | 84 | The difference is that Git stores its objects as individual files |
| 79 | 85 | in the ".git" folder or compressed into |
| 80 | -bespoke "pack-files", whereas Fossil stores its objects in a | |
| 86 | +bespoke "pack-files," whereas Fossil stores its objects in a | |
| 81 | 87 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 82 | 88 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 83 | 89 | Fossil uses a proven, general-purpose SQL database. This |
| 84 | 90 | difference is more than an implementation detail. It |
| 85 | 91 | has important consequences. |
| @@ -88,19 +94,19 @@ | ||
| 88 | 94 | by following the pointers embedded in the check-in object, but it is |
| 89 | 95 | difficult to go the other direction and locate the descendants of a |
| 90 | 96 | check-in. It is so difficult, in fact, that neither native Git nor |
| 91 | 97 | GitHub provide this capability. With Git, if you are looking at some |
| 92 | 98 | historical check-in then you cannot ask |
| 93 | -"what came next" or "what are the children of this check-in". | |
| 99 | +"What came next?" or "What are the children of this check-in?" | |
| 94 | 100 | |
| 95 | 101 | Fossil, on the other hand, parses essential information about check-ins |
| 96 | 102 | (parents, children, committers, comments, files changed, etc.) |
| 97 | 103 | into a relational database that can be easily |
| 98 | 104 | queried using concise SQL statements to find both ancestors and |
| 99 | 105 | descendents of a check-in. |
| 100 | 106 | |
| 101 | -Leaf check-ins in Git that lack a "ref" become "detached", making them | |
| 107 | +Leaf check-ins in Git that lack a "ref" become "detached," making them | |
| 102 | 108 | difficult to locate and subject to garbage collection. This |
| 103 | 109 | "detached head" problem has caused untold grief for countless |
| 104 | 110 | Git users. With Fossil, all check-ins are easily located using |
| 105 | 111 | a variety of attributes (parents, children, committer, date, full-text |
| 106 | 112 | search of the check-in comment) and so detached heads are simply not possible. |
| @@ -113,11 +119,12 @@ | ||
| 113 | 119 | and avoid errors. |
| 114 | 120 | |
| 115 | 121 | <h3>2.3 Cathedral vs. Bazaar</h3> |
| 116 | 122 | |
| 117 | 123 | Fossil and Git promote different development styles. Git promotes a |
| 118 | -"bazaar" development style in which numerous anonymous developers make | |
| 124 | +"[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|bazaar]" | |
| 125 | +development style in which numerous anonymous developers make | |
| 119 | 126 | small and sometimes haphazard contributions. Fossil |
| 120 | 127 | promotes a "cathedral" development model in which the project is |
| 121 | 128 | closely supervised by an highly engaged architect and implemented by |
| 122 | 129 | a clique of developers. |
| 123 | 130 | |
| @@ -142,21 +149,21 @@ | ||
| 142 | 149 | all developers and especially the project leader can maintain a better |
| 143 | 150 | mental picture of what is happening, and better situational awareness. |
| 144 | 151 | |
| 145 | 152 | <h3>2.4 Linux vs. SQLite</h3> |
| 146 | 153 | |
| 147 | -Git was specifically designed to support the development of Linux. | |
| 154 | +Git was specifically designed to support the development of the Linux kernel. | |
| 148 | 155 | Fossil was specifically designed to support the development of SQLite. |
| 149 | 156 | |
| 150 | -Both SQLite and Linux are important pieces of software. | |
| 151 | -SQLite is found on far more systems than Linux. (Almost every Linux | |
| 157 | +Both SQLite and the Linux kernel are important pieces of software. | |
| 158 | +SQLite is found on far more systems than Linux. Almost every Linux | |
| 152 | 159 | system uses SQLite, but there are many non-Linux systems such as |
| 153 | -iPhones, PlayStations, and Windows PCs that use SQLite.) On the other | |
| 160 | +iPhones, PlayStations, and Windows PCs that use SQLite. On the other | |
| 154 | 161 | hand, for those systems that do use Linux, Linux is a far more important |
| 155 | 162 | component. |
| 156 | 163 | |
| 157 | -Linux uses a bazaar-style development model. There are thousands and | |
| 164 | +The Linux kernel uses a bazaar-style development model. There are thousands and | |
| 158 | 165 | thousands of contributors, most of whom do not know each others names. |
| 159 | 166 | Git is designed for this scenario. |
| 160 | 167 | |
| 161 | 168 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 162 | 169 | comes from just three programmers, 64% from just the lead developer. |
| @@ -164,18 +171,18 @@ | ||
| 164 | 171 | Fossil is designed for this development model. |
| 165 | 172 | |
| 166 | 173 | <h3>2.5 Individual Branches vs. The Entire Change History</h3> |
| 167 | 174 | |
| 168 | 175 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 169 | -of changes. But Git tends to focus more on individual branches of | |
| 176 | +of changes, but Git tends to focus more on individual branches of | |
| 170 | 177 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 171 | 178 | |
| 172 | 179 | For example, the default "sync" behavior in Git is to only sync |
| 173 | 180 | a single branch, whereas with Fossil the only sync option it to |
| 174 | -sync the entire DAG. Git commands, and Git web interfaces such as | |
| 175 | -GitHub and/or GitLab, tend to show only a single branch at | |
| 176 | -a time, whereas Fossil usually shows all parallel branches all at | |
| 181 | +sync the entire DAG. Git commands, | |
| 182 | +GitHub, and GitLab tend to show only a single branch at | |
| 183 | +a time, whereas Fossil usually shows all parallel branches at | |
| 177 | 184 | once. Git has commands like "rebase" that help keep all relevant |
| 178 | 185 | changes on a single branch, whereas Fossil encourages a style of |
| 179 | 186 | many concurrent branches constantly springing into existance, |
| 180 | 187 | undergoing active development in parallel for a few days or weeks, then |
| 181 | 188 | merging back into the main line and disappearing. |
| @@ -199,17 +206,17 @@ | ||
| 199 | 206 | script or program to get it running. |
| 200 | 207 | |
| 201 | 208 | Fossil is a single self-contained stand-alone executable with hardly |
| 202 | 209 | any dependencies. Fossil can be (and often is) run inside a |
| 203 | 210 | minimally configured chroot jail. To install Fossil, |
| 204 | -one merely puts the executable on $PATH. | |
| 211 | +one merely puts the executable somewhere in the $PATH. | |
| 205 | 212 | |
| 206 | -The designer of Git says that the unix philosophy is to have lots of | |
| 213 | +The designer of Git says that the Unix philosophy is to have lots of | |
| 207 | 214 | small tools that collaborate to get the job done. The designer of |
| 208 | -Fossil says that the unix philosophy is "it just works". Both | |
| 215 | +Fossil says that the Unix philosophy is "It just works." Both | |
| 209 | 216 | individuals have written their DVCSes to reflect their own view |
| 210 | -of the "unix philosophy". | |
| 217 | +of the "Unix philosophy." | |
| 211 | 218 | |
| 212 | 219 | <h3>2.7 One vs. Many Check-outs per Repository</h3> |
| 213 | 220 | |
| 214 | 221 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 215 | 222 | of a single check-out. The check-out and the repository are located |
| @@ -220,17 +227,27 @@ | ||
| 220 | 227 | can be multiple active check-outs from the same repository, perhaps |
| 221 | 228 | open on different branches or on different snapshots of the same branch. |
| 222 | 229 | Long-running tests or builds can be running in one check-out while |
| 223 | 230 | changes are being committed in another. |
| 224 | 231 | |
| 225 | -(Update 2019-01-29:) | |
| 226 | -The check-out and the repository in Git used to be inseparable. | |
| 227 | -More recently, Git has been enhanced with the | |
| 228 | -"[https://git-scm.com/docs/git-worktree|worktree]" command that | |
| 229 | -allows a single repository to host multiple check-outs. However, | |
| 232 | +Git version 2.5 adds a feature to emulate Fossil's decoupling of the | |
| 233 | +repository from the check-out tree, which it calls | |
| 234 | +"[https://git-scm.com/docs/git-worktree|git-worktree]." This command | |
| 235 | +sets up a series of links in the filesystem to | |
| 236 | +allow a single repository to host multiple check-outs. However, | |
| 230 | 237 | the interface is sufficiently difficult to use that most people |
| 231 | 238 | find it easier to create a separate clone for each check-out. |
| 239 | +There are also practical consequences of the way it's implemented | |
| 240 | +that make worktrees not quite equivalent to the main Git repo + checkout | |
| 241 | +tree. | |
| 242 | + | |
| 243 | +With Fossil, the complete decoupling of repository and check-out tree | |
| 244 | +means every working check-out tree is treated equally. It's common in | |
| 245 | +Fossil to have a check-out tree for each major working branch so that | |
| 246 | +you can switch branches with a "cd" command rather than replace the | |
| 247 | +current working file set with a different file set by updating in place, | |
| 248 | +as Git prefers. | |
| 232 | 249 | |
| 233 | 250 | <h3>2.8 What you should have done vs. What you actually did</h3> |
| 234 | 251 | |
| 235 | 252 | Git puts a lot of emphasis on maintaining |
| 236 | 253 | a "clean" check-in history. Extraneous and experimental branches by |
| @@ -241,22 +258,23 @@ | ||
| 241 | 258 | mistakes. |
| 242 | 259 | |
| 243 | 260 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 244 | 261 | including all of the messy errors, dead-ends, experimental branches, and |
| 245 | 262 | so forth. One might argue that this |
| 246 | -makes the history of a Fossil project "messy". But another point of view | |
| 247 | -is that this makes the history "accurate". In actual practice, the | |
| 263 | +makes the history of a Fossil project "messy." But another point of view | |
| 264 | +is that this makes the history "accurate." In actual practice, the | |
| 248 | 265 | superior reporting tools available in Fossil mean that the added "mess" |
| 249 | 266 | is not a factor. |
| 250 | 267 | |
| 251 | 268 | One commentator has mused that Git records history according to |
| 252 | 269 | the victors, whereas Fossil records history as it actually happened. |
| 253 | 270 | |
| 254 | 271 | <h3>2.9 GPL vs. BSD</h3> |
| 255 | 272 | |
| 256 | 273 | Git is covered by the GPL license whereas Fossil is covered by |
| 257 | -a two-clause BSD license. | |
| 274 | +[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD | |
| 275 | +style license]. | |
| 258 | 276 | |
| 259 | 277 | Consider the difference between GPL and BSD licenses: GPL is designed |
| 260 | 278 | to make writing easier at the expense of making reading harder. BSD is |
| 261 | 279 | designed to make reading easier at the expense of making writing harder. |
| 262 | 280 | |
| @@ -289,11 +307,11 @@ | ||
| 289 | 307 | |
| 290 | 308 | <h2>3.0 Missing Features</h2> |
| 291 | 309 | |
| 292 | 310 | Most of the capabilities found in Git are also available in Fossil and |
| 293 | 311 | the other way around. For example, both systems have local check-outs, |
| 294 | -remote repositories, push/pull/sync, bisect capabilities, and a "stash". | |
| 312 | +remote repositories, push/pull/sync, bisect capabilities, and a "stash." | |
| 295 | 313 | Both systems store project history as a directed acyclic graph (DAG) |
| 296 | 314 | of immutable check-in objects. |
| 297 | 315 | |
| 298 | 316 | But there are a few capabilities in one system that are missing from the |
| 299 | 317 | other. |
| 300 | 318 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Versus Git</title> |
| 2 | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | you can easily [./inout.wiki | move your content]¹. |
| 7 | |
| 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | but they also have important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| @@ -13,13 +13,16 @@ | |
| 13 | Keep in mind that you are reading this on a Fossil website, and though |
| 14 | we try to be fair, the information here |
| 15 | might be biased in favor of Fossil. Ask around for second opinions from |
| 16 | people who have used <em>both</em> Fossil and Git. |
| 17 | |
| 18 | ¹<small><i>Git does not support |
| 19 | wiki, tickets, or tech-notes, so those elements will not transfer when |
| 20 | exporting from Fossil to Git.</i></small> |
| 21 | |
| 22 | <h2>2.0 Differences Between Fossil And Git</h2> |
| 23 | |
| 24 | Differences between Fossil and Git are summarized by the following table, |
| 25 | with further description in the text that follows. |
| @@ -26,14 +29,14 @@ | |
| 26 | |
| 27 | <blockquote><table border=1 cellpadding=5 align=center> |
| 28 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 29 | <tr><td>File versioning only</td> |
| 30 | <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> |
| 31 | <tr><td>Ad-hoc, pile-of-files key/value database</td> |
| 32 | <td>Relational SQL database</td></tr> |
| 33 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 34 | <tr><td>Designed for Linux development</td> |
| 35 | <td>Designed for SQLite development</td></tr> |
| 36 | <tr><td>Focus on individual branches</td> |
| 37 | <td>Focus on the entire tree of changes</td></tr> |
| 38 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 39 | <tr><td>One check-out per repository</td> |
| @@ -47,39 +50,42 @@ | |
| 47 | |
| 48 | Git provides file versioning services only, whereas Fossil adds |
| 49 | integrated [./wikitheory.wiki | wiki], |
| 50 | [./bugtheory.wiki | ticketing & bug tracking], |
| 51 | [./embeddeddoc.wiki | embedded documentation], |
| 52 | [./event.wiki | Technical notes], and a [./forum.wiki | forum]. |
| 53 | These additional capabilities are available for Git as 3rd-party and/or |
| 54 | user-installed add-ons, but with Fossil they are integrated into |
| 55 | the design. One way to describe Fossil is that it is |
| 56 | "[https://github.com/ | github]-in-a-box". |
| 57 | |
| 58 | If you clone Git's self-hosting repository you get just Git's source code. |
| 59 | If you clone Fossil's self-hosting repository, you get the entire |
| 60 | Fossil website - source code, documentation, ticket history, and so forth. |
| 61 | |
| 62 | For developers who choose to self-host projects (rather than using a |
| 63 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 64 | the stand-alone Fossil executable together with a 2-line CGI script |
| 65 | suffice to instantiate a full-featured developer website. To accomplish |
| 66 | the same using Git requires locating, installing, configuring, integrating, |
| 67 | and managing a wide assortment of separate tools. Standing up a developer |
| 68 | website using Fossil can be done in minutes, whereas doing the same using |
| 69 | Git requires hours or days. |
| 70 | |
| 71 | <h3>2.2 Database</h3> |
| 72 | |
| 73 | The baseline data structures for Fossil and Git are the same (modulo |
| 74 | formatting details). Both systems store check-ins as immutable |
| 75 | objects referencing their immediate ancestors and named by a |
| 76 | cryptographic hash of the check-in content. |
| 77 | |
| 78 | The difference is that Git stores its objects as individual files |
| 79 | in the ".git" folder or compressed into |
| 80 | bespoke "pack-files", whereas Fossil stores its objects in a |
| 81 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 82 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 83 | Fossil uses a proven, general-purpose SQL database. This |
| 84 | difference is more than an implementation detail. It |
| 85 | has important consequences. |
| @@ -88,19 +94,19 @@ | |
| 88 | by following the pointers embedded in the check-in object, but it is |
| 89 | difficult to go the other direction and locate the descendants of a |
| 90 | check-in. It is so difficult, in fact, that neither native Git nor |
| 91 | GitHub provide this capability. With Git, if you are looking at some |
| 92 | historical check-in then you cannot ask |
| 93 | "what came next" or "what are the children of this check-in". |
| 94 | |
| 95 | Fossil, on the other hand, parses essential information about check-ins |
| 96 | (parents, children, committers, comments, files changed, etc.) |
| 97 | into a relational database that can be easily |
| 98 | queried using concise SQL statements to find both ancestors and |
| 99 | descendents of a check-in. |
| 100 | |
| 101 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 102 | difficult to locate and subject to garbage collection. This |
| 103 | "detached head" problem has caused untold grief for countless |
| 104 | Git users. With Fossil, all check-ins are easily located using |
| 105 | a variety of attributes (parents, children, committer, date, full-text |
| 106 | search of the check-in comment) and so detached heads are simply not possible. |
| @@ -113,11 +119,12 @@ | |
| 113 | and avoid errors. |
| 114 | |
| 115 | <h3>2.3 Cathedral vs. Bazaar</h3> |
| 116 | |
| 117 | Fossil and Git promote different development styles. Git promotes a |
| 118 | "bazaar" development style in which numerous anonymous developers make |
| 119 | small and sometimes haphazard contributions. Fossil |
| 120 | promotes a "cathedral" development model in which the project is |
| 121 | closely supervised by an highly engaged architect and implemented by |
| 122 | a clique of developers. |
| 123 | |
| @@ -142,21 +149,21 @@ | |
| 142 | all developers and especially the project leader can maintain a better |
| 143 | mental picture of what is happening, and better situational awareness. |
| 144 | |
| 145 | <h3>2.4 Linux vs. SQLite</h3> |
| 146 | |
| 147 | Git was specifically designed to support the development of Linux. |
| 148 | Fossil was specifically designed to support the development of SQLite. |
| 149 | |
| 150 | Both SQLite and Linux are important pieces of software. |
| 151 | SQLite is found on far more systems than Linux. (Almost every Linux |
| 152 | system uses SQLite, but there are many non-Linux systems such as |
| 153 | iPhones, PlayStations, and Windows PCs that use SQLite.) On the other |
| 154 | hand, for those systems that do use Linux, Linux is a far more important |
| 155 | component. |
| 156 | |
| 157 | Linux uses a bazaar-style development model. There are thousands and |
| 158 | thousands of contributors, most of whom do not know each others names. |
| 159 | Git is designed for this scenario. |
| 160 | |
| 161 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 162 | comes from just three programmers, 64% from just the lead developer. |
| @@ -164,18 +171,18 @@ | |
| 164 | Fossil is designed for this development model. |
| 165 | |
| 166 | <h3>2.5 Individual Branches vs. The Entire Change History</h3> |
| 167 | |
| 168 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 169 | of changes. But Git tends to focus more on individual branches of |
| 170 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 171 | |
| 172 | For example, the default "sync" behavior in Git is to only sync |
| 173 | a single branch, whereas with Fossil the only sync option it to |
| 174 | sync the entire DAG. Git commands, and Git web interfaces such as |
| 175 | GitHub and/or GitLab, tend to show only a single branch at |
| 176 | a time, whereas Fossil usually shows all parallel branches all at |
| 177 | once. Git has commands like "rebase" that help keep all relevant |
| 178 | changes on a single branch, whereas Fossil encourages a style of |
| 179 | many concurrent branches constantly springing into existance, |
| 180 | undergoing active development in parallel for a few days or weeks, then |
| 181 | merging back into the main line and disappearing. |
| @@ -199,17 +206,17 @@ | |
| 199 | script or program to get it running. |
| 200 | |
| 201 | Fossil is a single self-contained stand-alone executable with hardly |
| 202 | any dependencies. Fossil can be (and often is) run inside a |
| 203 | minimally configured chroot jail. To install Fossil, |
| 204 | one merely puts the executable on $PATH. |
| 205 | |
| 206 | The designer of Git says that the unix philosophy is to have lots of |
| 207 | small tools that collaborate to get the job done. The designer of |
| 208 | Fossil says that the unix philosophy is "it just works". Both |
| 209 | individuals have written their DVCSes to reflect their own view |
| 210 | of the "unix philosophy". |
| 211 | |
| 212 | <h3>2.7 One vs. Many Check-outs per Repository</h3> |
| 213 | |
| 214 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 215 | of a single check-out. The check-out and the repository are located |
| @@ -220,17 +227,27 @@ | |
| 220 | can be multiple active check-outs from the same repository, perhaps |
| 221 | open on different branches or on different snapshots of the same branch. |
| 222 | Long-running tests or builds can be running in one check-out while |
| 223 | changes are being committed in another. |
| 224 | |
| 225 | (Update 2019-01-29:) |
| 226 | The check-out and the repository in Git used to be inseparable. |
| 227 | More recently, Git has been enhanced with the |
| 228 | "[https://git-scm.com/docs/git-worktree|worktree]" command that |
| 229 | allows a single repository to host multiple check-outs. However, |
| 230 | the interface is sufficiently difficult to use that most people |
| 231 | find it easier to create a separate clone for each check-out. |
| 232 | |
| 233 | <h3>2.8 What you should have done vs. What you actually did</h3> |
| 234 | |
| 235 | Git puts a lot of emphasis on maintaining |
| 236 | a "clean" check-in history. Extraneous and experimental branches by |
| @@ -241,22 +258,23 @@ | |
| 241 | mistakes. |
| 242 | |
| 243 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 244 | including all of the messy errors, dead-ends, experimental branches, and |
| 245 | so forth. One might argue that this |
| 246 | makes the history of a Fossil project "messy". But another point of view |
| 247 | is that this makes the history "accurate". In actual practice, the |
| 248 | superior reporting tools available in Fossil mean that the added "mess" |
| 249 | is not a factor. |
| 250 | |
| 251 | One commentator has mused that Git records history according to |
| 252 | the victors, whereas Fossil records history as it actually happened. |
| 253 | |
| 254 | <h3>2.9 GPL vs. BSD</h3> |
| 255 | |
| 256 | Git is covered by the GPL license whereas Fossil is covered by |
| 257 | a two-clause BSD license. |
| 258 | |
| 259 | Consider the difference between GPL and BSD licenses: GPL is designed |
| 260 | to make writing easier at the expense of making reading harder. BSD is |
| 261 | designed to make reading easier at the expense of making writing harder. |
| 262 | |
| @@ -289,11 +307,11 @@ | |
| 289 | |
| 290 | <h2>3.0 Missing Features</h2> |
| 291 | |
| 292 | Most of the capabilities found in Git are also available in Fossil and |
| 293 | the other way around. For example, both systems have local check-outs, |
| 294 | remote repositories, push/pull/sync, bisect capabilities, and a "stash". |
| 295 | Both systems store project history as a directed acyclic graph (DAG) |
| 296 | of immutable check-in objects. |
| 297 | |
| 298 | But there are a few capabilities in one system that are missing from the |
| 299 | other. |
| 300 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Versus Git</title> |
| 2 | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | you can easily [./inout.wiki | move your content].¹ |
| 7 | |
| 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | but they also have important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| @@ -13,13 +13,16 @@ | |
| 13 | Keep in mind that you are reading this on a Fossil website, and though |
| 14 | we try to be fair, the information here |
| 15 | might be biased in favor of Fossil. Ask around for second opinions from |
| 16 | people who have used <em>both</em> Fossil and Git. |
| 17 | |
| 18 | ¹<small><i>Git does not include a |
| 19 | wiki, a ticket tracker, a forum, or a tech-note feature, so those elements will not transfer when |
| 20 | exporting from Fossil to Git. GitHub adds some of these to stock Git, |
| 21 | but because they're not part of Git proper, [./mirrortogithub.md|exporting a Fossil |
| 22 | repository to GitHub] will still not include them; Fossil tickets do not |
| 23 | become GitHub issues, for example.</i></small> |
| 24 | |
| 25 | <h2>2.0 Differences Between Fossil And Git</h2> |
| 26 | |
| 27 | Differences between Fossil and Git are summarized by the following table, |
| 28 | with further description in the text that follows. |
| @@ -26,14 +29,14 @@ | |
| 29 | |
| 30 | <blockquote><table border=1 cellpadding=5 align=center> |
| 31 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 32 | <tr><td>File versioning only</td> |
| 33 | <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> |
| 34 | <tr><td>Ad-hoc pile-of-files key/value database</td> |
| 35 | <td>Relational SQL database</td></tr> |
| 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 37 | <tr><td>Designed for Linux kernel development</td> |
| 38 | <td>Designed for SQLite development</td></tr> |
| 39 | <tr><td>Focus on individual branches</td> |
| 40 | <td>Focus on the entire tree of changes</td></tr> |
| 41 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 42 | <tr><td>One check-out per repository</td> |
| @@ -47,39 +50,42 @@ | |
| 50 | |
| 51 | Git provides file versioning services only, whereas Fossil adds |
| 52 | integrated [./wikitheory.wiki | wiki], |
| 53 | [./bugtheory.wiki | ticketing & bug tracking], |
| 54 | [./embeddeddoc.wiki | embedded documentation], |
| 55 | [./event.wiki | technical notes], and a [./forum.wiki | forum]. |
| 56 | These additional capabilities are available for Git as 3rd-party |
| 57 | add-ons, but with Fossil they are integrated into |
| 58 | the design. One way to describe Fossil is that it is |
| 59 | "[https://github.com/ | GitHub]-in-a-box." |
| 60 | |
| 61 | If you clone [https://github.com/git/git|Git's self-hosting repository], |
| 62 | you get just Git's source code. |
| 63 | If you clone Fossil's self-hosting repository, you get the entire |
| 64 | Fossil website — source code, documentation, ticket history, and so forth. |
| 65 | That means you get a copy of this very article and all of its historical |
| 66 | versions, plus the same for all of the other public content on this site. |
| 67 | |
| 68 | For developers who choose to self-host projects (rather than using a |
| 69 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 70 | the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script] |
| 71 | suffice to instantiate a full-featured developer website. To accomplish |
| 72 | the same using Git requires locating, installing, configuring, integrating, |
| 73 | and managing a wide assortment of separate tools. Standing up a developer |
| 74 | website using Fossil can be done in minutes, whereas doing the same using |
| 75 | Git requires hours or days. |
| 76 | |
| 77 | <h3>2.2 Database</h3> |
| 78 | |
| 79 | The baseline data structures for Fossil and Git are the same, modulo |
| 80 | formatting details. Both systems store check-ins as immutable |
| 81 | objects referencing their immediate ancestors and named by a |
| 82 | cryptographic hash of the check-in content. |
| 83 | |
| 84 | The difference is that Git stores its objects as individual files |
| 85 | in the ".git" folder or compressed into |
| 86 | bespoke "pack-files," whereas Fossil stores its objects in a |
| 87 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 88 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 89 | Fossil uses a proven, general-purpose SQL database. This |
| 90 | difference is more than an implementation detail. It |
| 91 | has important consequences. |
| @@ -88,19 +94,19 @@ | |
| 94 | by following the pointers embedded in the check-in object, but it is |
| 95 | difficult to go the other direction and locate the descendants of a |
| 96 | check-in. It is so difficult, in fact, that neither native Git nor |
| 97 | GitHub provide this capability. With Git, if you are looking at some |
| 98 | historical check-in then you cannot ask |
| 99 | "What came next?" or "What are the children of this check-in?" |
| 100 | |
| 101 | Fossil, on the other hand, parses essential information about check-ins |
| 102 | (parents, children, committers, comments, files changed, etc.) |
| 103 | into a relational database that can be easily |
| 104 | queried using concise SQL statements to find both ancestors and |
| 105 | descendents of a check-in. |
| 106 | |
| 107 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 108 | difficult to locate and subject to garbage collection. This |
| 109 | "detached head" problem has caused untold grief for countless |
| 110 | Git users. With Fossil, all check-ins are easily located using |
| 111 | a variety of attributes (parents, children, committer, date, full-text |
| 112 | search of the check-in comment) and so detached heads are simply not possible. |
| @@ -113,11 +119,12 @@ | |
| 119 | and avoid errors. |
| 120 | |
| 121 | <h3>2.3 Cathedral vs. Bazaar</h3> |
| 122 | |
| 123 | Fossil and Git promote different development styles. Git promotes a |
| 124 | "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|bazaar]" |
| 125 | development style in which numerous anonymous developers make |
| 126 | small and sometimes haphazard contributions. Fossil |
| 127 | promotes a "cathedral" development model in which the project is |
| 128 | closely supervised by an highly engaged architect and implemented by |
| 129 | a clique of developers. |
| 130 | |
| @@ -142,21 +149,21 @@ | |
| 149 | all developers and especially the project leader can maintain a better |
| 150 | mental picture of what is happening, and better situational awareness. |
| 151 | |
| 152 | <h3>2.4 Linux vs. SQLite</h3> |
| 153 | |
| 154 | Git was specifically designed to support the development of the Linux kernel. |
| 155 | Fossil was specifically designed to support the development of SQLite. |
| 156 | |
| 157 | Both SQLite and the Linux kernel are important pieces of software. |
| 158 | SQLite is found on far more systems than Linux. Almost every Linux |
| 159 | system uses SQLite, but there are many non-Linux systems such as |
| 160 | iPhones, PlayStations, and Windows PCs that use SQLite. On the other |
| 161 | hand, for those systems that do use Linux, Linux is a far more important |
| 162 | component. |
| 163 | |
| 164 | The Linux kernel uses a bazaar-style development model. There are thousands and |
| 165 | thousands of contributors, most of whom do not know each others names. |
| 166 | Git is designed for this scenario. |
| 167 | |
| 168 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 169 | comes from just three programmers, 64% from just the lead developer. |
| @@ -164,18 +171,18 @@ | |
| 171 | Fossil is designed for this development model. |
| 172 | |
| 173 | <h3>2.5 Individual Branches vs. The Entire Change History</h3> |
| 174 | |
| 175 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 176 | of changes, but Git tends to focus more on individual branches of |
| 177 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 178 | |
| 179 | For example, the default "sync" behavior in Git is to only sync |
| 180 | a single branch, whereas with Fossil the only sync option it to |
| 181 | sync the entire DAG. Git commands, |
| 182 | GitHub, and GitLab tend to show only a single branch at |
| 183 | a time, whereas Fossil usually shows all parallel branches at |
| 184 | once. Git has commands like "rebase" that help keep all relevant |
| 185 | changes on a single branch, whereas Fossil encourages a style of |
| 186 | many concurrent branches constantly springing into existance, |
| 187 | undergoing active development in parallel for a few days or weeks, then |
| 188 | merging back into the main line and disappearing. |
| @@ -199,17 +206,17 @@ | |
| 206 | script or program to get it running. |
| 207 | |
| 208 | Fossil is a single self-contained stand-alone executable with hardly |
| 209 | any dependencies. Fossil can be (and often is) run inside a |
| 210 | minimally configured chroot jail. To install Fossil, |
| 211 | one merely puts the executable somewhere in the $PATH. |
| 212 | |
| 213 | The designer of Git says that the Unix philosophy is to have lots of |
| 214 | small tools that collaborate to get the job done. The designer of |
| 215 | Fossil says that the Unix philosophy is "It just works." Both |
| 216 | individuals have written their DVCSes to reflect their own view |
| 217 | of the "Unix philosophy." |
| 218 | |
| 219 | <h3>2.7 One vs. Many Check-outs per Repository</h3> |
| 220 | |
| 221 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 222 | of a single check-out. The check-out and the repository are located |
| @@ -220,17 +227,27 @@ | |
| 227 | can be multiple active check-outs from the same repository, perhaps |
| 228 | open on different branches or on different snapshots of the same branch. |
| 229 | Long-running tests or builds can be running in one check-out while |
| 230 | changes are being committed in another. |
| 231 | |
| 232 | Git version 2.5 adds a feature to emulate Fossil's decoupling of the |
| 233 | repository from the check-out tree, which it calls |
| 234 | "[https://git-scm.com/docs/git-worktree|git-worktree]." This command |
| 235 | sets up a series of links in the filesystem to |
| 236 | allow a single repository to host multiple check-outs. However, |
| 237 | the interface is sufficiently difficult to use that most people |
| 238 | find it easier to create a separate clone for each check-out. |
| 239 | There are also practical consequences of the way it's implemented |
| 240 | that make worktrees not quite equivalent to the main Git repo + checkout |
| 241 | tree. |
| 242 | |
| 243 | With Fossil, the complete decoupling of repository and check-out tree |
| 244 | means every working check-out tree is treated equally. It's common in |
| 245 | Fossil to have a check-out tree for each major working branch so that |
| 246 | you can switch branches with a "cd" command rather than replace the |
| 247 | current working file set with a different file set by updating in place, |
| 248 | as Git prefers. |
| 249 | |
| 250 | <h3>2.8 What you should have done vs. What you actually did</h3> |
| 251 | |
| 252 | Git puts a lot of emphasis on maintaining |
| 253 | a "clean" check-in history. Extraneous and experimental branches by |
| @@ -241,22 +258,23 @@ | |
| 258 | mistakes. |
| 259 | |
| 260 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 261 | including all of the messy errors, dead-ends, experimental branches, and |
| 262 | so forth. One might argue that this |
| 263 | makes the history of a Fossil project "messy." But another point of view |
| 264 | is that this makes the history "accurate." In actual practice, the |
| 265 | superior reporting tools available in Fossil mean that the added "mess" |
| 266 | is not a factor. |
| 267 | |
| 268 | One commentator has mused that Git records history according to |
| 269 | the victors, whereas Fossil records history as it actually happened. |
| 270 | |
| 271 | <h3>2.9 GPL vs. BSD</h3> |
| 272 | |
| 273 | Git is covered by the GPL license whereas Fossil is covered by |
| 274 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 275 | style license]. |
| 276 | |
| 277 | Consider the difference between GPL and BSD licenses: GPL is designed |
| 278 | to make writing easier at the expense of making reading harder. BSD is |
| 279 | designed to make reading easier at the expense of making writing harder. |
| 280 | |
| @@ -289,11 +307,11 @@ | |
| 307 | |
| 308 | <h2>3.0 Missing Features</h2> |
| 309 | |
| 310 | Most of the capabilities found in Git are also available in Fossil and |
| 311 | the other way around. For example, both systems have local check-outs, |
| 312 | remote repositories, push/pull/sync, bisect capabilities, and a "stash." |
| 313 | Both systems store project history as a directed acyclic graph (DAG) |
| 314 | of immutable check-in objects. |
| 315 | |
| 316 | But there are a few capabilities in one system that are missing from the |
| 317 | other. |
| 318 |