Fossil SCM
Removed manual indents on command examples in the branching doc; the skin does that now.
Commit
ccd880e435e189ac2f8bcb24b3d5bb5f43783422c60bda9309cd5f5c6032a0e4
Parent
b1a709a1a4edba7…
1 file changed
+5
-5
+5
-5
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -257,11 +257,11 @@ | ||
| 257 | 257 | |
| 258 | 258 | Fossil offers two primary ways to create named, intentional forks, |
| 259 | 259 | a.k.a. branches. First: |
| 260 | 260 | |
| 261 | 261 | <pre> |
| 262 | - $ fossil commit --branch my-new-branch-name | |
| 262 | +$ fossil commit --branch my-new-branch-name | |
| 263 | 263 | </pre> |
| 264 | 264 | |
| 265 | 265 | This is the method we recommend for most cases: it creates a branch as |
| 266 | 266 | part of a check-in using the version in the current checkout directory |
| 267 | 267 | as its basis. (This is normally the tip of the current branch, though |
| @@ -272,13 +272,13 @@ | ||
| 272 | 272 | tip check-in on that branch. |
| 273 | 273 | |
| 274 | 274 | The second, more complicated option is: |
| 275 | 275 | |
| 276 | 276 | <pre> |
| 277 | - $ fossil branch new my-new-branch-name trunk | |
| 278 | - $ fossil update my-new-branch-name | |
| 279 | - $ fossil commit | |
| 277 | +$ fossil branch new my-new-branch-name trunk | |
| 278 | +$ fossil update my-new-branch-name | |
| 279 | +$ fossil commit | |
| 280 | 280 | </pre> |
| 281 | 281 | |
| 282 | 282 | Not only is this three commands instead of one, the first of which is |
| 283 | 283 | longer than the entire simpler command above, you must give the second command |
| 284 | 284 | before creating any check-ins, because until you do, your local working |
| @@ -377,11 +377,11 @@ | ||
| 377 | 377 | |
| 378 | 378 | If your local checkout is on a forked branch, you can usually fix a fork |
| 379 | 379 | automatically with: |
| 380 | 380 | |
| 381 | 381 | <pre> |
| 382 | - $ fossil merge | |
| 382 | +$ fossil merge | |
| 383 | 383 | </pre> |
| 384 | 384 | |
| 385 | 385 | Normally you need to pass arguments to <b>fossil merge</b> to tell it |
| 386 | 386 | what you want to merge into the current basis view of the repository, |
| 387 | 387 | but without arguments, the command seeks out and fixes forks. |
| 388 | 388 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -257,11 +257,11 @@ | |
| 257 | |
| 258 | Fossil offers two primary ways to create named, intentional forks, |
| 259 | a.k.a. branches. First: |
| 260 | |
| 261 | <pre> |
| 262 | $ fossil commit --branch my-new-branch-name |
| 263 | </pre> |
| 264 | |
| 265 | This is the method we recommend for most cases: it creates a branch as |
| 266 | part of a check-in using the version in the current checkout directory |
| 267 | as its basis. (This is normally the tip of the current branch, though |
| @@ -272,13 +272,13 @@ | |
| 272 | tip check-in on that branch. |
| 273 | |
| 274 | The second, more complicated option is: |
| 275 | |
| 276 | <pre> |
| 277 | $ fossil branch new my-new-branch-name trunk |
| 278 | $ fossil update my-new-branch-name |
| 279 | $ fossil commit |
| 280 | </pre> |
| 281 | |
| 282 | Not only is this three commands instead of one, the first of which is |
| 283 | longer than the entire simpler command above, you must give the second command |
| 284 | before creating any check-ins, because until you do, your local working |
| @@ -377,11 +377,11 @@ | |
| 377 | |
| 378 | If your local checkout is on a forked branch, you can usually fix a fork |
| 379 | automatically with: |
| 380 | |
| 381 | <pre> |
| 382 | $ fossil merge |
| 383 | </pre> |
| 384 | |
| 385 | Normally you need to pass arguments to <b>fossil merge</b> to tell it |
| 386 | what you want to merge into the current basis view of the repository, |
| 387 | but without arguments, the command seeks out and fixes forks. |
| 388 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -257,11 +257,11 @@ | |
| 257 | |
| 258 | Fossil offers two primary ways to create named, intentional forks, |
| 259 | a.k.a. branches. First: |
| 260 | |
| 261 | <pre> |
| 262 | $ fossil commit --branch my-new-branch-name |
| 263 | </pre> |
| 264 | |
| 265 | This is the method we recommend for most cases: it creates a branch as |
| 266 | part of a check-in using the version in the current checkout directory |
| 267 | as its basis. (This is normally the tip of the current branch, though |
| @@ -272,13 +272,13 @@ | |
| 272 | tip check-in on that branch. |
| 273 | |
| 274 | The second, more complicated option is: |
| 275 | |
| 276 | <pre> |
| 277 | $ fossil branch new my-new-branch-name trunk |
| 278 | $ fossil update my-new-branch-name |
| 279 | $ fossil commit |
| 280 | </pre> |
| 281 | |
| 282 | Not only is this three commands instead of one, the first of which is |
| 283 | longer than the entire simpler command above, you must give the second command |
| 284 | before creating any check-ins, because until you do, your local working |
| @@ -377,11 +377,11 @@ | |
| 377 | |
| 378 | If your local checkout is on a forked branch, you can usually fix a fork |
| 379 | automatically with: |
| 380 | |
| 381 | <pre> |
| 382 | $ fossil merge |
| 383 | </pre> |
| 384 | |
| 385 | Normally you need to pass arguments to <b>fossil merge</b> to tell it |
| 386 | what you want to merge into the current basis view of the repository, |
| 387 | but without arguments, the command seeks out and fixes forks. |
| 388 |