Fossil SCM
Clarity tweaks to the new "multiple origins" scenario in the gitusers doc.
Commit
77bb3e4c33f9ff54fc4a9200fb9f2fe5d9425963a6ef47842c6ae14a2746a4ea
Parent
e67c413d505071c…
1 file changed
+17
-11
+17
-11
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -289,11 +289,24 @@ | ||
| 289 | 289 | repo up to the NAS: |
| 290 | 290 | |
| 291 | 291 | ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' |
| 292 | 292 | git push --all ssh://my-nas.local//SHARES/dayjob/repo.git |
| 293 | 293 | |
| 294 | -Now we can tell Git that there is a second origin, a “home” repo in | |
| 294 | +Realize that this is carefully optimized down to these two long | |
| 295 | +commands. In practice, typing these commands by hand, from memory, we’d | |
| 296 | +expect a normal user to need to give four or more commands here instead. | |
| 297 | +Packing the “`git init`” call into the “`ssh`” call is something more | |
| 298 | +done in scripts and documentation examples than is done interactively, | |
| 299 | +which then necessitates a third command before the push, “`exit`”. | |
| 300 | +There’s also a good chance that you’ll forget the need for the `--bare` | |
| 301 | +option here to avoid a fatal complaint from Git that the laptop can’t | |
| 302 | +push into a non-empty repo. If you fall into this trap, among the many | |
| 303 | +that Git lays for newbies, you have to nuke the incorrectly initted | |
| 304 | +repo, search the web and docs to find out about `--bare`, and try again. | |
| 305 | + | |
| 306 | +Having navigated that little minefield, | |
| 307 | +we can tell Git that there is a second origin, a “home” repo in | |
| 295 | 308 | addition to the named “work” repo we set up earlier: |
| 296 | 309 | |
| 297 | 310 | git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git |
| 298 | 311 | git config master.remote home |
| 299 | 312 | |
| @@ -366,16 +379,12 @@ | ||
| 366 | 379 | up to the NAS: |
| 367 | 380 | |
| 368 | 381 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 369 | 382 | |
| 370 | 383 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 371 | -relative the tricky “`git init && git push`” sequence above. It’d be | |
| 372 | -four commands instead of two if you weren’t clever enough to pack the | |
| 373 | -init into an `ssh` command, and unless you’re well versed with Git, | |
| 374 | -you’ll probably forget to give the `--bare` option the first time, | |
| 375 | -adding more commands as you blow the first attempt away and try again. | |
| 376 | -Contrast the Fossil alternative, which is almost impossible to get | |
| 384 | +relative the tricky “`git init && git push`” sequence above. | |
| 385 | +Fossil’s alternative is almost impossible to get | |
| 377 | 386 | wrong: copy this to that. *Done.* |
| 378 | 387 | |
| 379 | 388 | We’re relying on the `rsync` feature that creates up to one level of |
| 380 | 389 | missing directory (here, `dayjob/`) on the remote. If you know in |
| 381 | 390 | advance that the remote directory already exists, you could use a |
| @@ -392,14 +401,11 @@ | ||
| 392 | 401 | fossil remote home |
| 393 | 402 | |
| 394 | 403 | The first command is nearly identical to the Git version, but the second |
| 395 | 404 | is considerably simpler. And to be fair, you won’t find that second |
| 396 | 405 | command in all Git tutorials: the more common one we found with web |
| 397 | -searches is “`git push --set-upstream home master`”. Not only is it | |
| 398 | -longer, it’s wasteful to do it that way in the example above because | |
| 399 | -we’re working with a just-created remote clone of the local repo, so | |
| 400 | -doing this via “push” makes Git do pointless extra work. | |
| 406 | +searches is “`git push --set-upstream home master`”. | |
| 401 | 407 | |
| 402 | 408 | Where Fossil really wins is in the next step, making the initial commit |
| 403 | 409 | from home: |
| 404 | 410 | |
| 405 | 411 | fossil ci |
| 406 | 412 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -289,11 +289,24 @@ | |
| 289 | repo up to the NAS: |
| 290 | |
| 291 | ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' |
| 292 | git push --all ssh://my-nas.local//SHARES/dayjob/repo.git |
| 293 | |
| 294 | Now we can tell Git that there is a second origin, a “home” repo in |
| 295 | addition to the named “work” repo we set up earlier: |
| 296 | |
| 297 | git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git |
| 298 | git config master.remote home |
| 299 | |
| @@ -366,16 +379,12 @@ | |
| 366 | up to the NAS: |
| 367 | |
| 368 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 369 | |
| 370 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 371 | relative the tricky “`git init && git push`” sequence above. It’d be |
| 372 | four commands instead of two if you weren’t clever enough to pack the |
| 373 | init into an `ssh` command, and unless you’re well versed with Git, |
| 374 | you’ll probably forget to give the `--bare` option the first time, |
| 375 | adding more commands as you blow the first attempt away and try again. |
| 376 | Contrast the Fossil alternative, which is almost impossible to get |
| 377 | wrong: copy this to that. *Done.* |
| 378 | |
| 379 | We’re relying on the `rsync` feature that creates up to one level of |
| 380 | missing directory (here, `dayjob/`) on the remote. If you know in |
| 381 | advance that the remote directory already exists, you could use a |
| @@ -392,14 +401,11 @@ | |
| 392 | fossil remote home |
| 393 | |
| 394 | The first command is nearly identical to the Git version, but the second |
| 395 | is considerably simpler. And to be fair, you won’t find that second |
| 396 | command in all Git tutorials: the more common one we found with web |
| 397 | searches is “`git push --set-upstream home master`”. Not only is it |
| 398 | longer, it’s wasteful to do it that way in the example above because |
| 399 | we’re working with a just-created remote clone of the local repo, so |
| 400 | doing this via “push” makes Git do pointless extra work. |
| 401 | |
| 402 | Where Fossil really wins is in the next step, making the initial commit |
| 403 | from home: |
| 404 | |
| 405 | fossil ci |
| 406 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -289,11 +289,24 @@ | |
| 289 | repo up to the NAS: |
| 290 | |
| 291 | ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' |
| 292 | git push --all ssh://my-nas.local//SHARES/dayjob/repo.git |
| 293 | |
| 294 | Realize that this is carefully optimized down to these two long |
| 295 | commands. In practice, typing these commands by hand, from memory, we’d |
| 296 | expect a normal user to need to give four or more commands here instead. |
| 297 | Packing the “`git init`” call into the “`ssh`” call is something more |
| 298 | done in scripts and documentation examples than is done interactively, |
| 299 | which then necessitates a third command before the push, “`exit`”. |
| 300 | There’s also a good chance that you’ll forget the need for the `--bare` |
| 301 | option here to avoid a fatal complaint from Git that the laptop can’t |
| 302 | push into a non-empty repo. If you fall into this trap, among the many |
| 303 | that Git lays for newbies, you have to nuke the incorrectly initted |
| 304 | repo, search the web and docs to find out about `--bare`, and try again. |
| 305 | |
| 306 | Having navigated that little minefield, |
| 307 | we can tell Git that there is a second origin, a “home” repo in |
| 308 | addition to the named “work” repo we set up earlier: |
| 309 | |
| 310 | git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git |
| 311 | git config master.remote home |
| 312 | |
| @@ -366,16 +379,12 @@ | |
| 379 | up to the NAS: |
| 380 | |
| 381 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 382 | |
| 383 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 384 | relative the tricky “`git init && git push`” sequence above. |
| 385 | Fossil’s alternative is almost impossible to get |
| 386 | wrong: copy this to that. *Done.* |
| 387 | |
| 388 | We’re relying on the `rsync` feature that creates up to one level of |
| 389 | missing directory (here, `dayjob/`) on the remote. If you know in |
| 390 | advance that the remote directory already exists, you could use a |
| @@ -392,14 +401,11 @@ | |
| 401 | fossil remote home |
| 402 | |
| 403 | The first command is nearly identical to the Git version, but the second |
| 404 | is considerably simpler. And to be fair, you won’t find that second |
| 405 | command in all Git tutorials: the more common one we found with web |
| 406 | searches is “`git push --set-upstream home master`”. |
| 407 | |
| 408 | Where Fossil really wins is in the next step, making the initial commit |
| 409 | from home: |
| 410 | |
| 411 | fossil ci |
| 412 |