Fossil SCM
Assorted tweaks to the new material in the gitusers doc.
Commit
09acf696d27ddb5f6de1dcced2df6618a0013d669b8d916fd0a9e8624f031439
Parent
1299d67786a63a5…
1 file changed
+31
-19
+31
-19
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -30,18 +30,22 @@ | ||
| 30 | 30 | |
| 31 | 31 | A Fossil repository is a SQLite database in |
| 32 | 32 | which the entire history of a project is stored. A check-out is a |
| 33 | 33 | directory that contains a snapshot of your project that you |
| 34 | 34 | are currently working on, extracted for you from that database by the |
| 35 | -`fossil` program. See [the Fossil glossary][gloss] for more information. | |
| 35 | +`fossil` program. | |
| 36 | + | |
| 37 | +(See [the Fossil glossary][gloss] for more Fossil terms of art that may | |
| 38 | +be unfamiliar to a Git user.) | |
| 36 | 39 | |
| 37 | 40 | With Git, cloning a repository gets you what Fossil would call a |
| 38 | 41 | check-out directory with the repository stored in a `.git` subdirectory |
| 39 | 42 | of that check-out. There are methods to get more working directories |
| 40 | 43 | pointing at that same Git repository, but because it’s not designed into |
| 41 | 44 | the core concept of the tool, Git tutorials usually advocate a |
| 42 | -switch-in-place working mode instead. | |
| 45 | +switch-in-place working mode instead, so that is how most users end up | |
| 46 | +working with it. | |
| 43 | 47 | |
| 44 | 48 | Fossil can operate in the Git mode, switching between versions in a |
| 45 | 49 | single check-out directory: |
| 46 | 50 | |
| 47 | 51 | fossil clone https://example.com/repo /path/to/repo.fossil |
| @@ -114,29 +118,34 @@ | ||
| 114 | 118 | to rebuild outputs from files you yourself change. |
| 115 | 119 | |
| 116 | 120 | This style is also useful when a check-out directory may be tied up with |
| 117 | 121 | some long-running process, as with the “test” example above, where you |
| 118 | 122 | might need to run an hours-long brute-force replication script to tickle |
| 119 | -a [Heisenbug][hb]. While that runs, you can “`cd ../trunk`” and get back | |
| 123 | +a [Heisenbug][hb], forcing it to show itself. While that runs, you can “`cd ../trunk`” and get back | |
| 120 | 124 | to work. |
| 121 | 125 | |
| 122 | 126 | Git users may be initially confused by the `.fslckout` file at the root |
| 123 | -of a check-out directory. (Or with native Windows builds of Fossil, the | |
| 124 | -`_FOSSIL_` file, which is the same thing, so-named to get around the | |
| 125 | -historical 3-character extension limit with certain legacy filesystems.) | |
| 127 | +of a check-out directory. | |
| 126 | 128 | This is not the same thing as `.git`. It’s a per-checkout SQLite |
| 127 | 129 | database that keeps track of local state such as what version you have |
| 128 | -checked out, the contents of the stash for that working directory, the | |
| 129 | -[undo] buffers, per-checkout settings, and so forth. Largely what Fossil | |
| 130 | +checked out, the contents of the [stash] for that working directory, the | |
| 131 | +[undo] buffers, per-checkout [settings][set], and so forth. Largely what Fossil | |
| 130 | 132 | does when you ask it to [close] a check-out is to remove this file after |
| 131 | 133 | making certain safety checks. |
| 134 | + | |
| 135 | +(In native Windows builds of Fossil, this file is called `_FOSSIL_` | |
| 136 | +instead to get around the historical 3-character extension limit with | |
| 137 | +certain legacy filesystems. “Native” here is a distinction to exclude | |
| 138 | +Cygwin and WSL builds, which use `.fslckout`.) | |
| 132 | 139 | |
| 133 | 140 | [close]: /help?cmd=close |
| 134 | 141 | [gloss]: ./whyusefossil.wiki#definitions |
| 135 | 142 | [hb]: https://en.wikipedia.org/wiki/Heisenbug |
| 136 | 143 | [open]: /help?cmd=open |
| 144 | +[set]: /help?cmd=setting | |
| 137 | 145 | [server]: /help?cmd=server |
| 146 | +[stash]: /help?cmd=stash | |
| 138 | 147 | [undo]: /help?cmd=undo |
| 139 | 148 | |
| 140 | 149 | |
| 141 | 150 | <a id="staging"></a> |
| 142 | 151 | ## There Is No Staging Area |
| @@ -157,11 +166,11 @@ | ||
| 157 | 166 | Fossil prefers that you create new branches as part of the first commit |
| 158 | 167 | on that branch: |
| 159 | 168 | |
| 160 | 169 | fossil commit --branch my-new-branch |
| 161 | 170 | |
| 162 | -If that commit is successful, your local checkout directory is then | |
| 171 | +If that commit is successful, your local check-out directory is then | |
| 163 | 172 | switched to the tip of that branch, so subsequent commits don’t need the |
| 164 | 173 | “`--branch`” option. You have to switch back to the parent branch |
| 165 | 174 | explicitly, as with |
| 166 | 175 | |
| 167 | 176 | fossil update trunk # return to parent, “trunk” in this case |
| @@ -173,21 +182,22 @@ | ||
| 173 | 182 | fossil update my-new-branch |
| 174 | 183 | ...work on first commit... |
| 175 | 184 | fossil commit |
| 176 | 185 | |
| 177 | 186 | This is more verbose, but it has the same effect: put the first commit |
| 178 | -onto `my-new-branch` and switch the checkout directory to that branch so | |
| 187 | +onto `my-new-branch` and switch the check-out directory to that branch so | |
| 179 | 188 | subsequent commits are descendants of that initial branch commit. |
| 180 | 189 | |
| 181 | 190 | Fossil also allows you to move a check-in to a different branch |
| 182 | 191 | *after* you commit it, using the "`fossil amend`" command. |
| 183 | 192 | For example: |
| 184 | 193 | |
| 185 | 194 | fossil amend current --branch my-new-branch |
| 186 | 195 | |
| 187 | 196 | (“current” is one of the [special check-in names][scin] in Fossil. See |
| 188 | -that document for the many other names you can give to “`amend`”.) | |
| 197 | +that document for the many other names you can give to “`amend`”, or | |
| 198 | +indeed to any other Fossil command that accepts a “version” string.) | |
| 189 | 199 | |
| 190 | 200 | [scin]: ./checkin_names.wiki |
| 191 | 201 | |
| 192 | 202 | |
| 193 | 203 | <a id="autosync"></a> |
| @@ -219,14 +229,15 @@ | ||
| 219 | 229 | disconnected; your changes will sync up with the remote once you get |
| 220 | 230 | back online. |
| 221 | 231 | |
| 222 | 232 | 3. Because there is little distinction betwen the clones in the Fossil |
| 223 | 233 | model — unlike in Git, where clones often quickly diverge from each |
| 224 | - other, usually on purpose — the backup advantage applies in inverse | |
| 234 | + other, quite possibly on purpose — the backup advantage applies in inverse | |
| 225 | 235 | as well: if the remote server falls over dead, one of those with a |
| 226 | 236 | clone of that repository can stand it back up, and everyone can get |
| 227 | - back to work. If the remote comes back later, it can sync with the | |
| 237 | + back to work simply by re-pointing their local repo at the new | |
| 238 | + remote. If the failed remote comes back later, it can sync with the | |
| 228 | 239 | new central version, then perhaps take over as the primary source of |
| 229 | 240 | truth once again. |
| 230 | 241 | |
| 231 | 242 | (There are caveats to this, [covered elsewhere][bu].) |
| 232 | 243 | |
| @@ -458,11 +469,11 @@ | ||
| 458 | 469 | Unlike Git, Fossil’s “clone and open” feature doesn’t create the |
| 459 | 470 | directory for you, so we need an extra `mkdir` call here that isn’t |
| 460 | 471 | needed in the Git case. This is an indirect reflection of Fossil’s |
| 461 | 472 | [multiple working directories](#mwd) design philosophy: its |
| 462 | 473 | [`open` command][open] requires that you either issue it in an empty |
| 463 | -directory or one containing a prior closed checkout. In exchange for | |
| 474 | +directory or one containing a prior closed check-out. In exchange for | |
| 464 | 475 | this extra command, we get the advantage of Fossil’s |
| 465 | 476 | [superior handling][shwmd] of multiple working directories. To get the |
| 466 | 477 | full power of this feature, you’d switch from the “`fossil open URI`” |
| 467 | 478 | command form to the separate clone-and-open form shown in |
| 468 | 479 | [the quick start guide][qs], which adds one more command. |
| @@ -483,11 +494,11 @@ | ||
| 483 | 494 | up to the NAS: |
| 484 | 495 | |
| 485 | 496 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 486 | 497 | |
| 487 | 498 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 488 | -relative the tricky “`git init && git push`” sequence above. | |
| 499 | +relative to the tricky “`git init && git push`” sequence above. | |
| 489 | 500 | Fossil’s alternative is almost impossible to get |
| 490 | 501 | wrong: copy this to that. *Done.* |
| 491 | 502 | |
| 492 | 503 | We’re relying on the `rsync` feature that creates up to one level of |
| 493 | 504 | missing directory (here, `dayjob/`) on the remote. If you know in |
| @@ -503,13 +514,14 @@ | ||
| 503 | 514 | |
| 504 | 515 | fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil |
| 505 | 516 | fossil remote home |
| 506 | 517 | |
| 507 | 518 | The first command is nearly identical to the Git version, but the second |
| 508 | -is considerably simpler. And to be fair, you won’t find that second | |
| 509 | -command in all Git tutorials: the more common one we found with web | |
| 510 | -searches is “`git push --set-upstream home master`”. | |
| 519 | +is considerably simpler. And to be fair, you won’t find the | |
| 520 | +“`git config`” command above in all Git tutorials. The more common | |
| 521 | +alternative we found with web searches is even longer: | |
| 522 | +“`git push --set-upstream home master`”. | |
| 511 | 523 | |
| 512 | 524 | Where Fossil really wins is in the next step, making the initial commit |
| 513 | 525 | from home: |
| 514 | 526 | |
| 515 | 527 | fossil ci |
| @@ -522,13 +534,13 @@ | ||
| 522 | 534 | The “Friday afternoon sync-up” case is simpler, too: |
| 523 | 535 | |
| 524 | 536 | fossil remote work |
| 525 | 537 | fossil sync |
| 526 | 538 | |
| 527 | -Back at home, it’s even simpler: we can do away with the second command, | |
| 539 | +Back at home, it’s simpler still: we can do away with the second command, | |
| 528 | 540 | saying just “`fossil remote home`” because the sync will happen as part |
| 529 | 541 | of the next commit, thanks once again to Fossil’s autosync feature. |
| 530 | 542 | |
| 531 | 543 | [grsync]: https://stackoverflow.com/q/1398018/142454 |
| 532 | 544 | [qs]: ./quickstart.wiki |
| 533 | 545 | [shwmd]: ./fossil-v-git.wiki#checkouts |
| 534 | 546 | [sn]: https://en.wikipedia.org/wiki/Sneakernet |
| 535 | 547 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -30,18 +30,22 @@ | |
| 30 | |
| 31 | A Fossil repository is a SQLite database in |
| 32 | which the entire history of a project is stored. A check-out is a |
| 33 | directory that contains a snapshot of your project that you |
| 34 | are currently working on, extracted for you from that database by the |
| 35 | `fossil` program. See [the Fossil glossary][gloss] for more information. |
| 36 | |
| 37 | With Git, cloning a repository gets you what Fossil would call a |
| 38 | check-out directory with the repository stored in a `.git` subdirectory |
| 39 | of that check-out. There are methods to get more working directories |
| 40 | pointing at that same Git repository, but because it’s not designed into |
| 41 | the core concept of the tool, Git tutorials usually advocate a |
| 42 | switch-in-place working mode instead. |
| 43 | |
| 44 | Fossil can operate in the Git mode, switching between versions in a |
| 45 | single check-out directory: |
| 46 | |
| 47 | fossil clone https://example.com/repo /path/to/repo.fossil |
| @@ -114,29 +118,34 @@ | |
| 114 | to rebuild outputs from files you yourself change. |
| 115 | |
| 116 | This style is also useful when a check-out directory may be tied up with |
| 117 | some long-running process, as with the “test” example above, where you |
| 118 | might need to run an hours-long brute-force replication script to tickle |
| 119 | a [Heisenbug][hb]. While that runs, you can “`cd ../trunk`” and get back |
| 120 | to work. |
| 121 | |
| 122 | Git users may be initially confused by the `.fslckout` file at the root |
| 123 | of a check-out directory. (Or with native Windows builds of Fossil, the |
| 124 | `_FOSSIL_` file, which is the same thing, so-named to get around the |
| 125 | historical 3-character extension limit with certain legacy filesystems.) |
| 126 | This is not the same thing as `.git`. It’s a per-checkout SQLite |
| 127 | database that keeps track of local state such as what version you have |
| 128 | checked out, the contents of the stash for that working directory, the |
| 129 | [undo] buffers, per-checkout settings, and so forth. Largely what Fossil |
| 130 | does when you ask it to [close] a check-out is to remove this file after |
| 131 | making certain safety checks. |
| 132 | |
| 133 | [close]: /help?cmd=close |
| 134 | [gloss]: ./whyusefossil.wiki#definitions |
| 135 | [hb]: https://en.wikipedia.org/wiki/Heisenbug |
| 136 | [open]: /help?cmd=open |
| 137 | [server]: /help?cmd=server |
| 138 | [undo]: /help?cmd=undo |
| 139 | |
| 140 | |
| 141 | <a id="staging"></a> |
| 142 | ## There Is No Staging Area |
| @@ -157,11 +166,11 @@ | |
| 157 | Fossil prefers that you create new branches as part of the first commit |
| 158 | on that branch: |
| 159 | |
| 160 | fossil commit --branch my-new-branch |
| 161 | |
| 162 | If that commit is successful, your local checkout directory is then |
| 163 | switched to the tip of that branch, so subsequent commits don’t need the |
| 164 | “`--branch`” option. You have to switch back to the parent branch |
| 165 | explicitly, as with |
| 166 | |
| 167 | fossil update trunk # return to parent, “trunk” in this case |
| @@ -173,21 +182,22 @@ | |
| 173 | fossil update my-new-branch |
| 174 | ...work on first commit... |
| 175 | fossil commit |
| 176 | |
| 177 | This is more verbose, but it has the same effect: put the first commit |
| 178 | onto `my-new-branch` and switch the checkout directory to that branch so |
| 179 | subsequent commits are descendants of that initial branch commit. |
| 180 | |
| 181 | Fossil also allows you to move a check-in to a different branch |
| 182 | *after* you commit it, using the "`fossil amend`" command. |
| 183 | For example: |
| 184 | |
| 185 | fossil amend current --branch my-new-branch |
| 186 | |
| 187 | (“current” is one of the [special check-in names][scin] in Fossil. See |
| 188 | that document for the many other names you can give to “`amend`”.) |
| 189 | |
| 190 | [scin]: ./checkin_names.wiki |
| 191 | |
| 192 | |
| 193 | <a id="autosync"></a> |
| @@ -219,14 +229,15 @@ | |
| 219 | disconnected; your changes will sync up with the remote once you get |
| 220 | back online. |
| 221 | |
| 222 | 3. Because there is little distinction betwen the clones in the Fossil |
| 223 | model — unlike in Git, where clones often quickly diverge from each |
| 224 | other, usually on purpose — the backup advantage applies in inverse |
| 225 | as well: if the remote server falls over dead, one of those with a |
| 226 | clone of that repository can stand it back up, and everyone can get |
| 227 | back to work. If the remote comes back later, it can sync with the |
| 228 | new central version, then perhaps take over as the primary source of |
| 229 | truth once again. |
| 230 | |
| 231 | (There are caveats to this, [covered elsewhere][bu].) |
| 232 | |
| @@ -458,11 +469,11 @@ | |
| 458 | Unlike Git, Fossil’s “clone and open” feature doesn’t create the |
| 459 | directory for you, so we need an extra `mkdir` call here that isn’t |
| 460 | needed in the Git case. This is an indirect reflection of Fossil’s |
| 461 | [multiple working directories](#mwd) design philosophy: its |
| 462 | [`open` command][open] requires that you either issue it in an empty |
| 463 | directory or one containing a prior closed checkout. In exchange for |
| 464 | this extra command, we get the advantage of Fossil’s |
| 465 | [superior handling][shwmd] of multiple working directories. To get the |
| 466 | full power of this feature, you’d switch from the “`fossil open URI`” |
| 467 | command form to the separate clone-and-open form shown in |
| 468 | [the quick start guide][qs], which adds one more command. |
| @@ -483,11 +494,11 @@ | |
| 483 | up to the NAS: |
| 484 | |
| 485 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 486 | |
| 487 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 488 | relative the tricky “`git init && git push`” sequence above. |
| 489 | Fossil’s alternative is almost impossible to get |
| 490 | wrong: copy this to that. *Done.* |
| 491 | |
| 492 | We’re relying on the `rsync` feature that creates up to one level of |
| 493 | missing directory (here, `dayjob/`) on the remote. If you know in |
| @@ -503,13 +514,14 @@ | |
| 503 | |
| 504 | fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil |
| 505 | fossil remote home |
| 506 | |
| 507 | The first command is nearly identical to the Git version, but the second |
| 508 | is considerably simpler. And to be fair, you won’t find that second |
| 509 | command in all Git tutorials: the more common one we found with web |
| 510 | searches is “`git push --set-upstream home master`”. |
| 511 | |
| 512 | Where Fossil really wins is in the next step, making the initial commit |
| 513 | from home: |
| 514 | |
| 515 | fossil ci |
| @@ -522,13 +534,13 @@ | |
| 522 | The “Friday afternoon sync-up” case is simpler, too: |
| 523 | |
| 524 | fossil remote work |
| 525 | fossil sync |
| 526 | |
| 527 | Back at home, it’s even simpler: we can do away with the second command, |
| 528 | saying just “`fossil remote home`” because the sync will happen as part |
| 529 | of the next commit, thanks once again to Fossil’s autosync feature. |
| 530 | |
| 531 | [grsync]: https://stackoverflow.com/q/1398018/142454 |
| 532 | [qs]: ./quickstart.wiki |
| 533 | [shwmd]: ./fossil-v-git.wiki#checkouts |
| 534 | [sn]: https://en.wikipedia.org/wiki/Sneakernet |
| 535 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -30,18 +30,22 @@ | |
| 30 | |
| 31 | A Fossil repository is a SQLite database in |
| 32 | which the entire history of a project is stored. A check-out is a |
| 33 | directory that contains a snapshot of your project that you |
| 34 | are currently working on, extracted for you from that database by the |
| 35 | `fossil` program. |
| 36 | |
| 37 | (See [the Fossil glossary][gloss] for more Fossil terms of art that may |
| 38 | be unfamiliar to a Git user.) |
| 39 | |
| 40 | With Git, cloning a repository gets you what Fossil would call a |
| 41 | check-out directory with the repository stored in a `.git` subdirectory |
| 42 | of that check-out. There are methods to get more working directories |
| 43 | pointing at that same Git repository, but because it’s not designed into |
| 44 | the core concept of the tool, Git tutorials usually advocate a |
| 45 | switch-in-place working mode instead, so that is how most users end up |
| 46 | working with it. |
| 47 | |
| 48 | Fossil can operate in the Git mode, switching between versions in a |
| 49 | single check-out directory: |
| 50 | |
| 51 | fossil clone https://example.com/repo /path/to/repo.fossil |
| @@ -114,29 +118,34 @@ | |
| 118 | to rebuild outputs from files you yourself change. |
| 119 | |
| 120 | This style is also useful when a check-out directory may be tied up with |
| 121 | some long-running process, as with the “test” example above, where you |
| 122 | might need to run an hours-long brute-force replication script to tickle |
| 123 | a [Heisenbug][hb], forcing it to show itself. While that runs, you can “`cd ../trunk`” and get back |
| 124 | to work. |
| 125 | |
| 126 | Git users may be initially confused by the `.fslckout` file at the root |
| 127 | of a check-out directory. |
| 128 | This is not the same thing as `.git`. It’s a per-checkout SQLite |
| 129 | database that keeps track of local state such as what version you have |
| 130 | checked out, the contents of the [stash] for that working directory, the |
| 131 | [undo] buffers, per-checkout [settings][set], and so forth. Largely what Fossil |
| 132 | does when you ask it to [close] a check-out is to remove this file after |
| 133 | making certain safety checks. |
| 134 | |
| 135 | (In native Windows builds of Fossil, this file is called `_FOSSIL_` |
| 136 | instead to get around the historical 3-character extension limit with |
| 137 | certain legacy filesystems. “Native” here is a distinction to exclude |
| 138 | Cygwin and WSL builds, which use `.fslckout`.) |
| 139 | |
| 140 | [close]: /help?cmd=close |
| 141 | [gloss]: ./whyusefossil.wiki#definitions |
| 142 | [hb]: https://en.wikipedia.org/wiki/Heisenbug |
| 143 | [open]: /help?cmd=open |
| 144 | [set]: /help?cmd=setting |
| 145 | [server]: /help?cmd=server |
| 146 | [stash]: /help?cmd=stash |
| 147 | [undo]: /help?cmd=undo |
| 148 | |
| 149 | |
| 150 | <a id="staging"></a> |
| 151 | ## There Is No Staging Area |
| @@ -157,11 +166,11 @@ | |
| 166 | Fossil prefers that you create new branches as part of the first commit |
| 167 | on that branch: |
| 168 | |
| 169 | fossil commit --branch my-new-branch |
| 170 | |
| 171 | If that commit is successful, your local check-out directory is then |
| 172 | switched to the tip of that branch, so subsequent commits don’t need the |
| 173 | “`--branch`” option. You have to switch back to the parent branch |
| 174 | explicitly, as with |
| 175 | |
| 176 | fossil update trunk # return to parent, “trunk” in this case |
| @@ -173,21 +182,22 @@ | |
| 182 | fossil update my-new-branch |
| 183 | ...work on first commit... |
| 184 | fossil commit |
| 185 | |
| 186 | This is more verbose, but it has the same effect: put the first commit |
| 187 | onto `my-new-branch` and switch the check-out directory to that branch so |
| 188 | subsequent commits are descendants of that initial branch commit. |
| 189 | |
| 190 | Fossil also allows you to move a check-in to a different branch |
| 191 | *after* you commit it, using the "`fossil amend`" command. |
| 192 | For example: |
| 193 | |
| 194 | fossil amend current --branch my-new-branch |
| 195 | |
| 196 | (“current” is one of the [special check-in names][scin] in Fossil. See |
| 197 | that document for the many other names you can give to “`amend`”, or |
| 198 | indeed to any other Fossil command that accepts a “version” string.) |
| 199 | |
| 200 | [scin]: ./checkin_names.wiki |
| 201 | |
| 202 | |
| 203 | <a id="autosync"></a> |
| @@ -219,14 +229,15 @@ | |
| 229 | disconnected; your changes will sync up with the remote once you get |
| 230 | back online. |
| 231 | |
| 232 | 3. Because there is little distinction betwen the clones in the Fossil |
| 233 | model — unlike in Git, where clones often quickly diverge from each |
| 234 | other, quite possibly on purpose — the backup advantage applies in inverse |
| 235 | as well: if the remote server falls over dead, one of those with a |
| 236 | clone of that repository can stand it back up, and everyone can get |
| 237 | back to work simply by re-pointing their local repo at the new |
| 238 | remote. If the failed remote comes back later, it can sync with the |
| 239 | new central version, then perhaps take over as the primary source of |
| 240 | truth once again. |
| 241 | |
| 242 | (There are caveats to this, [covered elsewhere][bu].) |
| 243 | |
| @@ -458,11 +469,11 @@ | |
| 469 | Unlike Git, Fossil’s “clone and open” feature doesn’t create the |
| 470 | directory for you, so we need an extra `mkdir` call here that isn’t |
| 471 | needed in the Git case. This is an indirect reflection of Fossil’s |
| 472 | [multiple working directories](#mwd) design philosophy: its |
| 473 | [`open` command][open] requires that you either issue it in an empty |
| 474 | directory or one containing a prior closed check-out. In exchange for |
| 475 | this extra command, we get the advantage of Fossil’s |
| 476 | [superior handling][shwmd] of multiple working directories. To get the |
| 477 | full power of this feature, you’d switch from the “`fossil open URI`” |
| 478 | command form to the separate clone-and-open form shown in |
| 479 | [the quick start guide][qs], which adds one more command. |
| @@ -483,11 +494,11 @@ | |
| 494 | up to the NAS: |
| 495 | |
| 496 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 497 | |
| 498 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 499 | relative to the tricky “`git init && git push`” sequence above. |
| 500 | Fossil’s alternative is almost impossible to get |
| 501 | wrong: copy this to that. *Done.* |
| 502 | |
| 503 | We’re relying on the `rsync` feature that creates up to one level of |
| 504 | missing directory (here, `dayjob/`) on the remote. If you know in |
| @@ -503,13 +514,14 @@ | |
| 514 | |
| 515 | fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil |
| 516 | fossil remote home |
| 517 | |
| 518 | The first command is nearly identical to the Git version, but the second |
| 519 | is considerably simpler. And to be fair, you won’t find the |
| 520 | “`git config`” command above in all Git tutorials. The more common |
| 521 | alternative we found with web searches is even longer: |
| 522 | “`git push --set-upstream home master`”. |
| 523 | |
| 524 | Where Fossil really wins is in the next step, making the initial commit |
| 525 | from home: |
| 526 | |
| 527 | fossil ci |
| @@ -522,13 +534,13 @@ | |
| 534 | The “Friday afternoon sync-up” case is simpler, too: |
| 535 | |
| 536 | fossil remote work |
| 537 | fossil sync |
| 538 | |
| 539 | Back at home, it’s simpler still: we can do away with the second command, |
| 540 | saying just “`fossil remote home`” because the sync will happen as part |
| 541 | of the next commit, thanks once again to Fossil’s autosync feature. |
| 542 | |
| 543 | [grsync]: https://stackoverflow.com/q/1398018/142454 |
| 544 | [qs]: ./quickstart.wiki |
| 545 | [shwmd]: ./fossil-v-git.wiki#checkouts |
| 546 | [sn]: https://en.wikipedia.org/wiki/Sneakernet |
| 547 |