Fossil SCM
Minor documentation tweaks.
Commit
a3c5ce63cf3b42873259992137759b330759bf1716f51b4c39b6fbd4aa52032b
Parent
b517a989d61772c…
2 files changed
+12
+6
-3
+12
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -103,10 +103,22 @@ | ||
| 103 | 103 | |
| 104 | 104 | Fossil does not support the concept of syncing, pushing, or pulling |
| 105 | 105 | individual branches. When you sync/push/pull in Fossil, you sync/push/pull |
| 106 | 106 | everything - all branches, all wiki, all tickets, all forum posts, |
| 107 | 107 | all tags, all technotes - everything. |
| 108 | + | |
| 109 | +## The Main Branch Is Called "`trunk`", not "`master`" | |
| 110 | + | |
| 111 | +In Fossil, the traditional name and the default name for the main branch | |
| 112 | +is "`trunk`". The "`trunk`" branch in Fossil corresponds to the | |
| 113 | +"`master`" branch in Git. | |
| 114 | + | |
| 115 | +These naming conventions are so embedded in each system, that the | |
| 116 | +"trunk" branch name is automatically translated to "master" when | |
| 117 | +a [Fossil repo is mirrored to GitHub][6]. | |
| 118 | + | |
| 119 | +[6]: ./mirrortogithub.md | |
| 108 | 120 | |
| 109 | 121 | ## The "`fossil status`" Command Does Not Show Unmanaged Files |
| 110 | 122 | |
| 111 | 123 | The "`fossil status`" command shows you what files in your check-out have |
| 112 | 124 | been edited and scheduled for adding or removing at the next commit. |
| 113 | 125 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -103,10 +103,22 @@ | |
| 103 | |
| 104 | Fossil does not support the concept of syncing, pushing, or pulling |
| 105 | individual branches. When you sync/push/pull in Fossil, you sync/push/pull |
| 106 | everything - all branches, all wiki, all tickets, all forum posts, |
| 107 | all tags, all technotes - everything. |
| 108 | |
| 109 | ## The "`fossil status`" Command Does Not Show Unmanaged Files |
| 110 | |
| 111 | The "`fossil status`" command shows you what files in your check-out have |
| 112 | been edited and scheduled for adding or removing at the next commit. |
| 113 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -103,10 +103,22 @@ | |
| 103 | |
| 104 | Fossil does not support the concept of syncing, pushing, or pulling |
| 105 | individual branches. When you sync/push/pull in Fossil, you sync/push/pull |
| 106 | everything - all branches, all wiki, all tickets, all forum posts, |
| 107 | all tags, all technotes - everything. |
| 108 | |
| 109 | ## The Main Branch Is Called "`trunk`", not "`master`" |
| 110 | |
| 111 | In Fossil, the traditional name and the default name for the main branch |
| 112 | is "`trunk`". The "`trunk`" branch in Fossil corresponds to the |
| 113 | "`master`" branch in Git. |
| 114 | |
| 115 | These naming conventions are so embedded in each system, that the |
| 116 | "trunk" branch name is automatically translated to "master" when |
| 117 | a [Fossil repo is mirrored to GitHub][6]. |
| 118 | |
| 119 | [6]: ./mirrortogithub.md |
| 120 | |
| 121 | ## The "`fossil status`" Command Does Not Show Unmanaged Files |
| 122 | |
| 123 | The "`fossil status`" command shows you what files in your check-out have |
| 124 | been edited and scheduled for adding or removing at the next commit. |
| 125 |
+6
-3
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -199,18 +199,19 @@ | ||
| 199 | 199 | might commit different changes against the same check-in. This |
| 200 | 200 | results in one parent node having two or more children. |
| 201 | 201 | <li><p>Command: <b>merge</b> → |
| 202 | 202 | combines the work of multiple check-ins into |
| 203 | 203 | a single check-out. That check-out can then be committed to create |
| 204 | - a new that has two (or more) parents. | |
| 204 | + a new check-in that has two (or more) parents. | |
| 205 | 205 | <ul> |
| 206 | 206 | <li><p>Most check-ins have just one parent, and either zero or |
| 207 | 207 | one child. |
| 208 | 208 | <li><p>When a check-in has two or more parents, one of those parents |
| 209 | - is the "primary parent". All the other parent nodes are "secondary". | |
| 209 | + is the "primary parent". All the other parent nodes are "secondary" | |
| 210 | + or "merge" parents. | |
| 210 | 211 | Conceptually, the primary parent shows the main line of |
| 211 | - development. Content from the secondary parents is added | |
| 212 | + development. Content from the merge parents is added | |
| 212 | 213 | into the main line. |
| 213 | 214 | <li><p>The "direct children" of a check-in X are all children that |
| 214 | 215 | have X as their primary parent. |
| 215 | 216 | <li><p>A check-in node with no direct children is sometimes called |
| 216 | 217 | a "leaf". |
| @@ -221,10 +222,12 @@ | ||
| 221 | 222 | <li><p>Definition: <b>branch</b> → |
| 222 | 223 | a sequence of check-ins that are all linked |
| 223 | 224 | together in the DAG through the primary parent. |
| 224 | 225 | <ul> |
| 225 | 226 | <li><p>Branches are often given names which propagate to direct children. |
| 227 | + The tradition in Fossil is to call the main branch "trunk". In | |
| 228 | + Git, the main branch is usually called "master". | |
| 226 | 229 | <li><p>It is possible to have multiple branches with the same name. |
| 227 | 230 | Fossil has no problem with this, but it can be confusing to |
| 228 | 231 | humans, so best practice is to give each branch a unique name. |
| 229 | 232 | <li><p>The name of a branch can be changed by adding special tags |
| 230 | 233 | to the first check-in of a branch. The name assigned by this |
| 231 | 234 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -199,18 +199,19 @@ | |
| 199 | might commit different changes against the same check-in. This |
| 200 | results in one parent node having two or more children. |
| 201 | <li><p>Command: <b>merge</b> → |
| 202 | combines the work of multiple check-ins into |
| 203 | a single check-out. That check-out can then be committed to create |
| 204 | a new that has two (or more) parents. |
| 205 | <ul> |
| 206 | <li><p>Most check-ins have just one parent, and either zero or |
| 207 | one child. |
| 208 | <li><p>When a check-in has two or more parents, one of those parents |
| 209 | is the "primary parent". All the other parent nodes are "secondary". |
| 210 | Conceptually, the primary parent shows the main line of |
| 211 | development. Content from the secondary parents is added |
| 212 | into the main line. |
| 213 | <li><p>The "direct children" of a check-in X are all children that |
| 214 | have X as their primary parent. |
| 215 | <li><p>A check-in node with no direct children is sometimes called |
| 216 | a "leaf". |
| @@ -221,10 +222,12 @@ | |
| 221 | <li><p>Definition: <b>branch</b> → |
| 222 | a sequence of check-ins that are all linked |
| 223 | together in the DAG through the primary parent. |
| 224 | <ul> |
| 225 | <li><p>Branches are often given names which propagate to direct children. |
| 226 | <li><p>It is possible to have multiple branches with the same name. |
| 227 | Fossil has no problem with this, but it can be confusing to |
| 228 | humans, so best practice is to give each branch a unique name. |
| 229 | <li><p>The name of a branch can be changed by adding special tags |
| 230 | to the first check-in of a branch. The name assigned by this |
| 231 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -199,18 +199,19 @@ | |
| 199 | might commit different changes against the same check-in. This |
| 200 | results in one parent node having two or more children. |
| 201 | <li><p>Command: <b>merge</b> → |
| 202 | combines the work of multiple check-ins into |
| 203 | a single check-out. That check-out can then be committed to create |
| 204 | a new check-in that has two (or more) parents. |
| 205 | <ul> |
| 206 | <li><p>Most check-ins have just one parent, and either zero or |
| 207 | one child. |
| 208 | <li><p>When a check-in has two or more parents, one of those parents |
| 209 | is the "primary parent". All the other parent nodes are "secondary" |
| 210 | or "merge" parents. |
| 211 | Conceptually, the primary parent shows the main line of |
| 212 | development. Content from the merge parents is added |
| 213 | into the main line. |
| 214 | <li><p>The "direct children" of a check-in X are all children that |
| 215 | have X as their primary parent. |
| 216 | <li><p>A check-in node with no direct children is sometimes called |
| 217 | a "leaf". |
| @@ -221,10 +222,12 @@ | |
| 222 | <li><p>Definition: <b>branch</b> → |
| 223 | a sequence of check-ins that are all linked |
| 224 | together in the DAG through the primary parent. |
| 225 | <ul> |
| 226 | <li><p>Branches are often given names which propagate to direct children. |
| 227 | The tradition in Fossil is to call the main branch "trunk". In |
| 228 | Git, the main branch is usually called "master". |
| 229 | <li><p>It is possible to have multiple branches with the same name. |
| 230 | Fossil has no problem with this, but it can be confusing to |
| 231 | humans, so best practice is to give each branch a unique name. |
| 232 | <li><p>The name of a branch can be changed by adding special tags |
| 233 | to the first check-in of a branch. The name assigned by this |
| 234 |