Fossil SCM
Fix typos in the fossil-v-git.wiki document.
Commit
5566c8535ae3c0af98cf064bd3d370a197ba6867
Parent
a6725ea5c5b924b…
1 file changed
+4
-4
+4
-4
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -4,11 +4,11 @@ | ||
| 4 | 4 | |
| 5 | 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | 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 | -but there are also important differences. | |
| 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. |
| 12 | 12 | |
| 13 | 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | 14 | so the information here |
| @@ -40,11 +40,11 @@ | ||
| 40 | 40 | |
| 41 | 41 | <h2>3.0 Discussion</h2> |
| 42 | 42 | |
| 43 | 43 | <h3>3.1 Feature Set</h3> |
| 44 | 44 | |
| 45 | -Git provides file versioning services only, whereas Fossil adds an | |
| 45 | +Git provides file versioning services only, whereas Fossil adds | |
| 46 | 46 | integrated [./wikitheory.wiki | wiki], |
| 47 | 47 | [./bugtheory.wiki | ticketing & bug tracking], |
| 48 | 48 | [./embeddeddoc.wiki | embedded documentation], and |
| 49 | 49 | [./event.wiki | Technical notes]. |
| 50 | 50 | These additional capabilities are available for Git as 3rd-party and/or |
| @@ -79,11 +79,11 @@ | ||
| 79 | 79 | Fossil uses a proven, general-purpose SQL database. This |
| 80 | 80 | difference is more than an implementation detail. It |
| 81 | 81 | has important consequences. |
| 82 | 82 | |
| 83 | 83 | With Git, one can easily locate the ancestors of a particular check-in |
| 84 | -by following the pointers embedded the check-in object, but it is | |
| 84 | +by following the pointers embedded in the check-in object, but it is | |
| 85 | 85 | difficult to go the other direction and locate the descendants of a |
| 86 | 86 | check-in. It is so difficult, in fact, that neither native Git nor |
| 87 | 87 | GitHub provide this capability. With Git, if you are looking at some |
| 88 | 88 | historical check-in then you cannot ask |
| 89 | 89 | "what came next" or "what are the children of this check-in". |
| @@ -122,11 +122,11 @@ | ||
| 122 | 122 | They can be. But those modes are not their design intent nor the their |
| 123 | 123 | low-friction path. |
| 124 | 124 | |
| 125 | 125 | Git encourages a style in which individual developers work in relative |
| 126 | 126 | isolation, maintaining their |
| 127 | -own branches and the occasionally rebasing and pushing selected changes up | |
| 127 | +own branches and occasionally rebasing and pushing selected changes up | |
| 128 | 128 | to the main repository. Developers using Git often have their own |
| 129 | 129 | private branches that nobody else ever sees. Work becomes siloed. |
| 130 | 130 | This is exactly what one wants when doing bazaar-style development. |
| 131 | 131 | |
| 132 | 132 | Fossil, in contrast, strives to keep all changes from all contributors |
| 133 | 133 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -4,11 +4,11 @@ | |
| 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 there are also important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| 12 | |
| 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | so the information here |
| @@ -40,11 +40,11 @@ | |
| 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 an |
| 46 | integrated [./wikitheory.wiki | wiki], |
| 47 | [./bugtheory.wiki | ticketing & bug tracking], |
| 48 | [./embeddeddoc.wiki | embedded documentation], and |
| 49 | [./event.wiki | Technical notes]. |
| 50 | These additional capabilities are available for Git as 3rd-party and/or |
| @@ -79,11 +79,11 @@ | |
| 79 | Fossil uses a proven, general-purpose SQL database. This |
| 80 | difference is more than an implementation detail. It |
| 81 | has important consequences. |
| 82 | |
| 83 | With Git, one can easily locate the ancestors of a particular check-in |
| 84 | by following the pointers embedded the check-in object, but it is |
| 85 | difficult to go the other direction and locate the descendants of a |
| 86 | check-in. It is so difficult, in fact, that neither native Git nor |
| 87 | GitHub provide this capability. With Git, if you are looking at some |
| 88 | historical check-in then you cannot ask |
| 89 | "what came next" or "what are the children of this check-in". |
| @@ -122,11 +122,11 @@ | |
| 122 | They can be. But those modes are not their design intent nor the their |
| 123 | low-friction path. |
| 124 | |
| 125 | Git encourages a style in which individual developers work in relative |
| 126 | isolation, maintaining their |
| 127 | own branches and the occasionally rebasing and pushing selected changes up |
| 128 | to the main repository. Developers using Git often have their own |
| 129 | private branches that nobody else ever sees. Work becomes siloed. |
| 130 | This is exactly what one wants when doing bazaar-style development. |
| 131 | |
| 132 | Fossil, in contrast, strives to keep all changes from all contributors |
| 133 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -4,11 +4,11 @@ | |
| 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. |
| 12 | |
| 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | so the information here |
| @@ -40,11 +40,11 @@ | |
| 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 |
| 49 | [./event.wiki | Technical notes]. |
| 50 | These additional capabilities are available for Git as 3rd-party and/or |
| @@ -79,11 +79,11 @@ | |
| 79 | Fossil uses a proven, general-purpose SQL database. This |
| 80 | difference is more than an implementation detail. It |
| 81 | has important consequences. |
| 82 | |
| 83 | With Git, one can easily locate the ancestors of a particular check-in |
| 84 | by following the pointers embedded in the check-in object, but it is |
| 85 | difficult to go the other direction and locate the descendants of a |
| 86 | check-in. It is so difficult, in fact, that neither native Git nor |
| 87 | GitHub provide this capability. With Git, if you are looking at some |
| 88 | historical check-in then you cannot ask |
| 89 | "what came next" or "what are the children of this check-in". |
| @@ -122,11 +122,11 @@ | |
| 122 | They can be. But those modes are not their design intent nor the their |
| 123 | low-friction path. |
| 124 | |
| 125 | Git encourages a style in which individual developers work in relative |
| 126 | isolation, maintaining their |
| 127 | own branches and occasionally rebasing and pushing selected changes up |
| 128 | to the main repository. Developers using Git often have their own |
| 129 | private branches that nobody else ever sees. Work becomes siloed. |
| 130 | This is exactly what one wants when doing bazaar-style development. |
| 131 | |
| 132 | Fossil, in contrast, strives to keep all changes from all contributors |
| 133 |