Fossil SCM
More tweaks to the fossil-v-git.wiki document.
Commit
6ae97be7a7edbca7fce33999195d52e0fa385233c59249b11f27d564dd4d0764
Parent
ce4fb80e868ebd2…
1 file changed
+15
-14
+15
-14
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -17,11 +17,14 @@ | ||
| 17 | 17 | |
| 18 | 18 | ¹<small><i>Git does not support |
| 19 | 19 | wiki, tickets, or tech-notes, so those elements will not transfer when |
| 20 | 20 | exporting from Fossil to Git.</i></small> |
| 21 | 21 | |
| 22 | -<h2>2.0 Executive Summary:</h2> | |
| 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. | |
| 23 | 26 | |
| 24 | 27 | <blockquote><table border=1 cellpadding=5 align=center> |
| 25 | 28 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 26 | 29 | <tr><td>File versioning only</td> |
| 27 | 30 | <td>Versioning, Tickets, Wiki, and Technotes</td></tr> |
| @@ -36,13 +39,11 @@ | ||
| 36 | 39 | <tr><td>Remembers what you should have done</td> |
| 37 | 40 | <td>Remembers what you actually did</td></tr> |
| 38 | 41 | <tr><td>GPL</td><td>BSD</td></tr> |
| 39 | 42 | </table></blockquote> |
| 40 | 43 | |
| 41 | -<h2>3.0 Discussion</h2> | |
| 42 | - | |
| 43 | -<h3>3.1 Feature Set</h3> | |
| 44 | +<h3>2.1 Feature Set</h3> | |
| 44 | 45 | |
| 45 | 46 | Git provides file versioning services only, whereas Fossil adds |
| 46 | 47 | integrated [./wikitheory.wiki | wiki], |
| 47 | 48 | [./bugtheory.wiki | ticketing & bug tracking], |
| 48 | 49 | [./embeddeddoc.wiki | embedded documentation], and |
| @@ -63,11 +64,11 @@ | ||
| 63 | 64 | the same using Git requires locating, installing, configuring, integrating, |
| 64 | 65 | and managing a wide assortment of separate tools. Standing up a developer |
| 65 | 66 | website using Fossil can be done in minutes, whereas doing the same using |
| 66 | 67 | Git requires hours or days. |
| 67 | 68 | |
| 68 | -<h3>3.2 Database</h3> | |
| 69 | +<h3>2.2 Database</h3> | |
| 69 | 70 | |
| 70 | 71 | The baseline data structures for Fossil and Git are the same (modulo |
| 71 | 72 | formatting details). Both systems store check-ins as immutable |
| 72 | 73 | objects referencing their immediate ancestors and named by a |
| 73 | 74 | cryptographic hash of the check-in content. |
| @@ -107,11 +108,11 @@ | ||
| 107 | 108 | ([./webpage-ex.md|examples]) that show project state |
| 108 | 109 | in ways that help developers |
| 109 | 110 | maintain enhanced awareness and comprehension |
| 110 | 111 | and avoid errors. |
| 111 | 112 | |
| 112 | -<h3>3.3 Cathedral vs. Bazaar</h3> | |
| 113 | +<h3>2.3 Cathedral vs. Bazaar</h3> | |
| 113 | 114 | |
| 114 | 115 | Fossil and Git promote different development styles. Git promotes a |
| 115 | 116 | "bazaar" development style in which numerous anonymous developers make |
| 116 | 117 | small and sometimes haphazard contributions. Fossil |
| 117 | 118 | promotes a "cathedral" development model in which the project is |
| @@ -137,11 +138,11 @@ | ||
| 137 | 138 | to integrate. Fossil places a lot of emphasis on reporting the state |
| 138 | 139 | of the project, and the changes underway by all developers, so that |
| 139 | 140 | all developers and especially the project leader can maintain a better |
| 140 | 141 | mental picture of what is happening, and better situational awareness. |
| 141 | 142 | |
| 142 | -<h3>3.4 Linux vs. SQLite</h3> | |
| 143 | +<h3>2.4 Linux vs. SQLite</h3> | |
| 143 | 144 | |
| 144 | 145 | Git was specifically designed to support the development of Linux. |
| 145 | 146 | Fossil was specifically designed to support the development of SQLite. |
| 146 | 147 | |
| 147 | 148 | Both SQLite and Linux are important pieces of software. |
| @@ -158,11 +159,11 @@ | ||
| 158 | 159 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 159 | 160 | comes from just three programmers, 64% from just the lead developer. |
| 160 | 161 | And all SQLite developers know each other well and interact daily. |
| 161 | 162 | Fossil is designed for this development model. |
| 162 | 163 | |
| 163 | -<h3>3.5 Lots of little tools vs. Self-contained system</h3> | |
| 164 | +<h3>2.5 Lots of little tools vs. Self-contained system</h3> | |
| 164 | 165 | |
| 165 | 166 | Git consists of many small tools, each doing one small part of the job, |
| 166 | 167 | which can be recombined (by experts) to perform powerful operations. |
| 167 | 168 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 168 | 169 | script or program to get it running. |
| @@ -176,11 +177,11 @@ | ||
| 176 | 177 | small tools that collaborate to get the job done. The designer of |
| 177 | 178 | Fossil says that the unix philosophy is "it just works". Both |
| 178 | 179 | individuals have written their DVCSes to reflect their own view |
| 179 | 180 | of the "unix philosophy". |
| 180 | 181 | |
| 181 | -<h3>3.6 One vs. Many Check-outs per Repository</h3> | |
| 182 | +<h3>2.6 One vs. Many Check-outs per Repository</h3> | |
| 182 | 183 | |
| 183 | 184 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 184 | 185 | of a single check-out. The check-out and the repository are inseperable. |
| 185 | 186 | |
| 186 | 187 | With Fossil, a "repository" is a single SQLite database file |
| @@ -188,11 +189,11 @@ | ||
| 188 | 189 | can be multiple active check-outs from the same repository, perhaps |
| 189 | 190 | open on different branches or on different snapshots of the same branch. |
| 190 | 191 | Long-running tests or builds can be running in one check-out while |
| 191 | 192 | changes are being committed in another. |
| 192 | 193 | |
| 193 | -<h3>3.7 What you should have done vs. What you actually did</h3> | |
| 194 | +<h3>2.7 What you should have done vs. What you actually did</h3> | |
| 194 | 195 | |
| 195 | 196 | Git puts a lot of emphasis on maintaining |
| 196 | 197 | a "clean" check-in history. Extraneous and experimental branches by |
| 197 | 198 | individual developers often never make it into the main repository. And |
| 198 | 199 | branches are often rebased before being pushed, to make |
| @@ -209,11 +210,11 @@ | ||
| 209 | 210 | is not a factor. |
| 210 | 211 | |
| 211 | 212 | One commentator has mused that Git records history according to |
| 212 | 213 | the victors, whereas Fossil records history as it actually happened. |
| 213 | 214 | |
| 214 | -<h3>3.8 GPL vs. BSD</h3> | |
| 215 | +<h3>2.8 GPL vs. BSD</h3> | |
| 215 | 216 | |
| 216 | 217 | Git is covered by the GPL license whereas Fossil is covered by |
| 217 | 218 | a two-clause BSD license. |
| 218 | 219 | |
| 219 | 220 | Consider the difference between GPL and BSD licenses: GPL is designed |
| @@ -245,11 +246,11 @@ | ||
| 245 | 246 | more BSD-oriented world-view in Fossil. Git encourages anonymous contributions |
| 246 | 247 | and siloed development, which are hallmarks of the GPL/bazaar approach to |
| 247 | 248 | software, whereas Fossil encourages a more tightly collaborative, |
| 248 | 249 | cliquish, cathedral-style approach more typical of BSD-licensed projects. |
| 249 | 250 | |
| 250 | -<h2>4.0 Missing Features</h2> | |
| 251 | +<h2>3.0 Missing Features</h2> | |
| 251 | 252 | |
| 252 | 253 | Most of the capabilities found in Git are also available in Fossil and |
| 253 | 254 | the other way around. For example, both systems have local check-outs, |
| 254 | 255 | remote repositories, push/pull/sync, bisect capabilities, and a "stash". |
| 255 | 256 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -256,11 +257,11 @@ | ||
| 256 | 257 | of immutable check-in objects. |
| 257 | 258 | |
| 258 | 259 | But there are a few capabilities in one system that are missing from the |
| 259 | 260 | other. |
| 260 | 261 | |
| 261 | -<h3>4.1 Features found in Fossil but missing from Git</h3> | |
| 262 | +<h3>3.1 Features found in Fossil but missing from Git</h3> | |
| 262 | 263 | |
| 263 | 264 | * <b>The ability to show descendents of a check-in.</b> |
| 264 | 265 | |
| 265 | 266 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 266 | 267 | only Fossil shows the descendents. (It is possible to find the |
| @@ -295,11 +296,11 @@ | ||
| 295 | 296 | Fossil supports an integrated web interface. Some of the same features |
| 296 | 297 | are available using third-party add-ons for Git, but they do not provide |
| 297 | 298 | nearly as many features and they are not nearly as convenient to use. |
| 298 | 299 | |
| 299 | 300 | |
| 300 | -<h3>4.2 Features found in Git but missing from Fossil</h3> | |
| 301 | +<h3>3.2 Features found in Git but missing from Fossil</h3> | |
| 301 | 302 | |
| 302 | 303 | * <b>Rebase</b> |
| 303 | 304 | |
| 304 | 305 | Because of its emphasis on recording history exactly as it happened, |
| 305 | 306 | rather than as we would have liked it to happen, Fossil deliberately |
| 306 | 307 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -17,11 +17,14 @@ | |
| 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 Executive Summary:</h2> |
| 23 | |
| 24 | <blockquote><table border=1 cellpadding=5 align=center> |
| 25 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 26 | <tr><td>File versioning only</td> |
| 27 | <td>Versioning, Tickets, Wiki, and Technotes</td></tr> |
| @@ -36,13 +39,11 @@ | |
| 36 | <tr><td>Remembers what you should have done</td> |
| 37 | <td>Remembers what you actually did</td></tr> |
| 38 | <tr><td>GPL</td><td>BSD</td></tr> |
| 39 | </table></blockquote> |
| 40 | |
| 41 | <h2>3.0 Discussion</h2> |
| 42 | |
| 43 | <h3>3.1 Feature Set</h3> |
| 44 | |
| 45 | Git provides file versioning services only, whereas Fossil adds |
| 46 | integrated [./wikitheory.wiki | wiki], |
| 47 | [./bugtheory.wiki | ticketing & bug tracking], |
| 48 | [./embeddeddoc.wiki | embedded documentation], and |
| @@ -63,11 +64,11 @@ | |
| 63 | the same using Git requires locating, installing, configuring, integrating, |
| 64 | and managing a wide assortment of separate tools. Standing up a developer |
| 65 | website using Fossil can be done in minutes, whereas doing the same using |
| 66 | Git requires hours or days. |
| 67 | |
| 68 | <h3>3.2 Database</h3> |
| 69 | |
| 70 | The baseline data structures for Fossil and Git are the same (modulo |
| 71 | formatting details). Both systems store check-ins as immutable |
| 72 | objects referencing their immediate ancestors and named by a |
| 73 | cryptographic hash of the check-in content. |
| @@ -107,11 +108,11 @@ | |
| 107 | ([./webpage-ex.md|examples]) that show project state |
| 108 | in ways that help developers |
| 109 | maintain enhanced awareness and comprehension |
| 110 | and avoid errors. |
| 111 | |
| 112 | <h3>3.3 Cathedral vs. Bazaar</h3> |
| 113 | |
| 114 | Fossil and Git promote different development styles. Git promotes a |
| 115 | "bazaar" development style in which numerous anonymous developers make |
| 116 | small and sometimes haphazard contributions. Fossil |
| 117 | promotes a "cathedral" development model in which the project is |
| @@ -137,11 +138,11 @@ | |
| 137 | to integrate. Fossil places a lot of emphasis on reporting the state |
| 138 | of the project, and the changes underway by all developers, so that |
| 139 | all developers and especially the project leader can maintain a better |
| 140 | mental picture of what is happening, and better situational awareness. |
| 141 | |
| 142 | <h3>3.4 Linux vs. SQLite</h3> |
| 143 | |
| 144 | Git was specifically designed to support the development of Linux. |
| 145 | Fossil was specifically designed to support the development of SQLite. |
| 146 | |
| 147 | Both SQLite and Linux are important pieces of software. |
| @@ -158,11 +159,11 @@ | |
| 158 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 159 | comes from just three programmers, 64% from just the lead developer. |
| 160 | And all SQLite developers know each other well and interact daily. |
| 161 | Fossil is designed for this development model. |
| 162 | |
| 163 | <h3>3.5 Lots of little tools vs. Self-contained system</h3> |
| 164 | |
| 165 | Git consists of many small tools, each doing one small part of the job, |
| 166 | which can be recombined (by experts) to perform powerful operations. |
| 167 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 168 | script or program to get it running. |
| @@ -176,11 +177,11 @@ | |
| 176 | small tools that collaborate to get the job done. The designer of |
| 177 | Fossil says that the unix philosophy is "it just works". Both |
| 178 | individuals have written their DVCSes to reflect their own view |
| 179 | of the "unix philosophy". |
| 180 | |
| 181 | <h3>3.6 One vs. Many Check-outs per Repository</h3> |
| 182 | |
| 183 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 184 | of a single check-out. The check-out and the repository are inseperable. |
| 185 | |
| 186 | With Fossil, a "repository" is a single SQLite database file |
| @@ -188,11 +189,11 @@ | |
| 188 | can be multiple active check-outs from the same repository, perhaps |
| 189 | open on different branches or on different snapshots of the same branch. |
| 190 | Long-running tests or builds can be running in one check-out while |
| 191 | changes are being committed in another. |
| 192 | |
| 193 | <h3>3.7 What you should have done vs. What you actually did</h3> |
| 194 | |
| 195 | Git puts a lot of emphasis on maintaining |
| 196 | a "clean" check-in history. Extraneous and experimental branches by |
| 197 | individual developers often never make it into the main repository. And |
| 198 | branches are often rebased before being pushed, to make |
| @@ -209,11 +210,11 @@ | |
| 209 | is not a factor. |
| 210 | |
| 211 | One commentator has mused that Git records history according to |
| 212 | the victors, whereas Fossil records history as it actually happened. |
| 213 | |
| 214 | <h3>3.8 GPL vs. BSD</h3> |
| 215 | |
| 216 | Git is covered by the GPL license whereas Fossil is covered by |
| 217 | a two-clause BSD license. |
| 218 | |
| 219 | Consider the difference between GPL and BSD licenses: GPL is designed |
| @@ -245,11 +246,11 @@ | |
| 245 | more BSD-oriented world-view in Fossil. Git encourages anonymous contributions |
| 246 | and siloed development, which are hallmarks of the GPL/bazaar approach to |
| 247 | software, whereas Fossil encourages a more tightly collaborative, |
| 248 | cliquish, cathedral-style approach more typical of BSD-licensed projects. |
| 249 | |
| 250 | <h2>4.0 Missing Features</h2> |
| 251 | |
| 252 | Most of the capabilities found in Git are also available in Fossil and |
| 253 | the other way around. For example, both systems have local check-outs, |
| 254 | remote repositories, push/pull/sync, bisect capabilities, and a "stash". |
| 255 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -256,11 +257,11 @@ | |
| 256 | of immutable check-in objects. |
| 257 | |
| 258 | But there are a few capabilities in one system that are missing from the |
| 259 | other. |
| 260 | |
| 261 | <h3>4.1 Features found in Fossil but missing from Git</h3> |
| 262 | |
| 263 | * <b>The ability to show descendents of a check-in.</b> |
| 264 | |
| 265 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 266 | only Fossil shows the descendents. (It is possible to find the |
| @@ -295,11 +296,11 @@ | |
| 295 | Fossil supports an integrated web interface. Some of the same features |
| 296 | are available using third-party add-ons for Git, but they do not provide |
| 297 | nearly as many features and they are not nearly as convenient to use. |
| 298 | |
| 299 | |
| 300 | <h3>4.2 Features found in Git but missing from Fossil</h3> |
| 301 | |
| 302 | * <b>Rebase</b> |
| 303 | |
| 304 | Because of its emphasis on recording history exactly as it happened, |
| 305 | rather than as we would have liked it to happen, Fossil deliberately |
| 306 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -17,11 +17,14 @@ | |
| 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 | |
| 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, and Technotes</td></tr> |
| @@ -36,13 +39,11 @@ | |
| 39 | <tr><td>Remembers what you should have done</td> |
| 40 | <td>Remembers what you actually did</td></tr> |
| 41 | <tr><td>GPL</td><td>BSD</td></tr> |
| 42 | </table></blockquote> |
| 43 | |
| 44 | <h3>2.1 Feature Set</h3> |
| 45 | |
| 46 | Git provides file versioning services only, whereas Fossil adds |
| 47 | integrated [./wikitheory.wiki | wiki], |
| 48 | [./bugtheory.wiki | ticketing & bug tracking], |
| 49 | [./embeddeddoc.wiki | embedded documentation], and |
| @@ -63,11 +64,11 @@ | |
| 64 | the same using Git requires locating, installing, configuring, integrating, |
| 65 | and managing a wide assortment of separate tools. Standing up a developer |
| 66 | website using Fossil can be done in minutes, whereas doing the same using |
| 67 | Git requires hours or days. |
| 68 | |
| 69 | <h3>2.2 Database</h3> |
| 70 | |
| 71 | The baseline data structures for Fossil and Git are the same (modulo |
| 72 | formatting details). Both systems store check-ins as immutable |
| 73 | objects referencing their immediate ancestors and named by a |
| 74 | cryptographic hash of the check-in content. |
| @@ -107,11 +108,11 @@ | |
| 108 | ([./webpage-ex.md|examples]) that show project state |
| 109 | in ways that help developers |
| 110 | maintain enhanced awareness and comprehension |
| 111 | and avoid errors. |
| 112 | |
| 113 | <h3>2.3 Cathedral vs. Bazaar</h3> |
| 114 | |
| 115 | Fossil and Git promote different development styles. Git promotes a |
| 116 | "bazaar" development style in which numerous anonymous developers make |
| 117 | small and sometimes haphazard contributions. Fossil |
| 118 | promotes a "cathedral" development model in which the project is |
| @@ -137,11 +138,11 @@ | |
| 138 | to integrate. Fossil places a lot of emphasis on reporting the state |
| 139 | of the project, and the changes underway by all developers, so that |
| 140 | all developers and especially the project leader can maintain a better |
| 141 | mental picture of what is happening, and better situational awareness. |
| 142 | |
| 143 | <h3>2.4 Linux vs. SQLite</h3> |
| 144 | |
| 145 | Git was specifically designed to support the development of Linux. |
| 146 | Fossil was specifically designed to support the development of SQLite. |
| 147 | |
| 148 | Both SQLite and Linux are important pieces of software. |
| @@ -158,11 +159,11 @@ | |
| 159 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 160 | comes from just three programmers, 64% from just the lead developer. |
| 161 | And all SQLite developers know each other well and interact daily. |
| 162 | Fossil is designed for this development model. |
| 163 | |
| 164 | <h3>2.5 Lots of little tools vs. Self-contained system</h3> |
| 165 | |
| 166 | Git consists of many small tools, each doing one small part of the job, |
| 167 | which can be recombined (by experts) to perform powerful operations. |
| 168 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 169 | script or program to get it running. |
| @@ -176,11 +177,11 @@ | |
| 177 | small tools that collaborate to get the job done. The designer of |
| 178 | Fossil says that the unix philosophy is "it just works". Both |
| 179 | individuals have written their DVCSes to reflect their own view |
| 180 | of the "unix philosophy". |
| 181 | |
| 182 | <h3>2.6 One vs. Many Check-outs per Repository</h3> |
| 183 | |
| 184 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 185 | of a single check-out. The check-out and the repository are inseperable. |
| 186 | |
| 187 | With Fossil, a "repository" is a single SQLite database file |
| @@ -188,11 +189,11 @@ | |
| 189 | can be multiple active check-outs from the same repository, perhaps |
| 190 | open on different branches or on different snapshots of the same branch. |
| 191 | Long-running tests or builds can be running in one check-out while |
| 192 | changes are being committed in another. |
| 193 | |
| 194 | <h3>2.7 What you should have done vs. What you actually did</h3> |
| 195 | |
| 196 | Git puts a lot of emphasis on maintaining |
| 197 | a "clean" check-in history. Extraneous and experimental branches by |
| 198 | individual developers often never make it into the main repository. And |
| 199 | branches are often rebased before being pushed, to make |
| @@ -209,11 +210,11 @@ | |
| 210 | is not a factor. |
| 211 | |
| 212 | One commentator has mused that Git records history according to |
| 213 | the victors, whereas Fossil records history as it actually happened. |
| 214 | |
| 215 | <h3>2.8 GPL vs. BSD</h3> |
| 216 | |
| 217 | Git is covered by the GPL license whereas Fossil is covered by |
| 218 | a two-clause BSD license. |
| 219 | |
| 220 | Consider the difference between GPL and BSD licenses: GPL is designed |
| @@ -245,11 +246,11 @@ | |
| 246 | more BSD-oriented world-view in Fossil. Git encourages anonymous contributions |
| 247 | and siloed development, which are hallmarks of the GPL/bazaar approach to |
| 248 | software, whereas Fossil encourages a more tightly collaborative, |
| 249 | cliquish, cathedral-style approach more typical of BSD-licensed projects. |
| 250 | |
| 251 | <h2>3.0 Missing Features</h2> |
| 252 | |
| 253 | Most of the capabilities found in Git are also available in Fossil and |
| 254 | the other way around. For example, both systems have local check-outs, |
| 255 | remote repositories, push/pull/sync, bisect capabilities, and a "stash". |
| 256 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -256,11 +257,11 @@ | |
| 257 | of immutable check-in objects. |
| 258 | |
| 259 | But there are a few capabilities in one system that are missing from the |
| 260 | other. |
| 261 | |
| 262 | <h3>3.1 Features found in Fossil but missing from Git</h3> |
| 263 | |
| 264 | * <b>The ability to show descendents of a check-in.</b> |
| 265 | |
| 266 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 267 | only Fossil shows the descendents. (It is possible to find the |
| @@ -295,11 +296,11 @@ | |
| 296 | Fossil supports an integrated web interface. Some of the same features |
| 297 | are available using third-party add-ons for Git, but they do not provide |
| 298 | nearly as many features and they are not nearly as convenient to use. |
| 299 | |
| 300 | |
| 301 | <h3>3.2 Features found in Git but missing from Fossil</h3> |
| 302 | |
| 303 | * <b>Rebase</b> |
| 304 | |
| 305 | Because of its emphasis on recording history exactly as it happened, |
| 306 | rather than as we would have liked it to happen, Fossil deliberately |
| 307 |