Fossil SCM
Backed out all the extra whitespace in command examples in the gitusers doc now that the skin handles indenting for us.
Commit
d3eae1875c813ba70796513f65b0bacf51f4c4418c7d679fb245596a39f39017
Parent
d67009e521d0333…
1 file changed
+108
-108
+108
-108
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -73,15 +73,15 @@ | ||
| 73 | 73 | document][ckwf] to see the practical differences. |
| 74 | 74 | |
| 75 | 75 | There is one Git-specific detail we wish to add beyond what that |
| 76 | 76 | document already covers. This command: |
| 77 | 77 | |
| 78 | - git checkout some-branch | |
| 78 | + git checkout some-branch | |
| 79 | 79 | |
| 80 | 80 | …is best given as: |
| 81 | 81 | |
| 82 | - fossil update some-branch | |
| 82 | + fossil update some-branch | |
| 83 | 83 | |
| 84 | 84 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 85 | 85 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 86 | 86 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 87 | 87 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| @@ -109,11 +109,11 @@ | ||
| 109 | 109 | |
| 110 | 110 | The `fossil pull` command is simply the reverse of |
| 111 | 111 | `fossil push`, so that `fossil sync` [is functionally equivalent |
| 112 | 112 | to](./sync.wiki#sync): |
| 113 | 113 | |
| 114 | - fossil push ; fossil pull | |
| 114 | + fossil push ; fossil pull | |
| 115 | 115 | |
| 116 | 116 | There is no implicit “and update the local working directory” step in Fossil’s |
| 117 | 117 | push, pull, or sync commands, as there is with `git pull`. |
| 118 | 118 | |
| 119 | 119 | Someone coming from the Git perspective may perceive that `fossil up` |
| @@ -180,29 +180,29 @@ | ||
| 180 | 180 | check-out directories][mcw] with Git. |
| 181 | 181 | |
| 182 | 182 | The old way is to simply symlink the `.git` directory between working |
| 183 | 183 | trees: |
| 184 | 184 | |
| 185 | - mkdir ../foo-branch | |
| 186 | - ln -s ../actual-clone-dir/.git . | |
| 187 | - git checkout foo-branch | |
| 185 | + mkdir ../foo-branch | |
| 186 | + ln -s ../actual-clone-dir/.git . | |
| 187 | + git checkout foo-branch | |
| 188 | 188 | |
| 189 | 189 | The symlink trick has a number of problems, the largest being that |
| 190 | 190 | symlinks weren’t available on Windows until Vista, and until the Windows |
| 191 | 191 | 10 Creators Update was released in spring of 2017, you had to be an |
| 192 | 192 | Administrator to use the feature besides. ([Source][wsyml]) Git 2.5 solved |
| 193 | 193 | this problem back when Windows XP was Microsoft’s current offering |
| 194 | 194 | by adding the `git-worktree` command: |
| 195 | 195 | |
| 196 | - git worktree add ../foo-branch foo-branch | |
| 197 | - cd ../foo-branch | |
| 196 | + git worktree add ../foo-branch foo-branch | |
| 197 | + cd ../foo-branch | |
| 198 | 198 | |
| 199 | 199 | That is approximately equivalent to this in Fossil: |
| 200 | 200 | |
| 201 | - mkdir ../foo-branch | |
| 202 | - cd ../foo-branch | |
| 203 | - fossil open /path/to/repo.fossil foo-branch | |
| 201 | + mkdir ../foo-branch | |
| 202 | + cd ../foo-branch | |
| 203 | + fossil open /path/to/repo.fossil foo-branch | |
| 204 | 204 | |
| 205 | 205 | The Fossil alternative is wordier, but since this tends to be one-time setup, |
| 206 | 206 | not something you do everyday, the overhead is insignificant. This author keeps a “scratch” check-out |
| 207 | 207 | for cases where it’s inappropriate to reuse the “trunk” check-out, |
| 208 | 208 | isolating all of my expedient switch-in-place actions to that one |
| @@ -211,20 +211,20 @@ | ||
| 211 | 211 | up, I rarely pay the cost of these wordier commands. |
| 212 | 212 | |
| 213 | 213 | That then leads us to the closest equivalent in Git to [closing a Fossil |
| 214 | 214 | check-out](#close): |
| 215 | 215 | |
| 216 | - git worktree remove . | |
| 216 | + git worktree remove . | |
| 217 | 217 | |
| 218 | 218 | Note, however, that unlike `fossil close`, once the Git command |
| 219 | 219 | determines that there are no uncommitted changes, it blows away all of |
| 220 | 220 | the checked-out files! Fossil’s alternative is shorter, easier to |
| 221 | 221 | remember, and safer. |
| 222 | 222 | |
| 223 | 223 | There’s another way to get Fossil-like separate worktrees in Git: |
| 224 | 224 | |
| 225 | - git clone --separate-git-dir repo.git https://example.com/repo | |
| 225 | + git clone --separate-git-dir repo.git https://example.com/repo | |
| 226 | 226 | |
| 227 | 227 | This allows you to have your Git repository directory entirely separate |
| 228 | 228 | from your working tree, with `.git` in the check-out directory being a |
| 229 | 229 | file that points to `../repo.git`, in this example. |
| 230 | 230 | |
| @@ -238,22 +238,22 @@ | ||
| 238 | 238 | from working directory creates in practice, consider this common Git “init in place” |
| 239 | 239 | method for creating a new repository from an existing tree of files, |
| 240 | 240 | perhaps because you are placing that project under version control for |
| 241 | 241 | the first time: |
| 242 | 242 | |
| 243 | - cd long-established-project | |
| 244 | - git init | |
| 245 | - git add * | |
| 246 | - git commit -m "Initial commit of project." | |
| 243 | + cd long-established-project | |
| 244 | + git init | |
| 245 | + git add * | |
| 246 | + git commit -m "Initial commit of project." | |
| 247 | 247 | |
| 248 | 248 | The closest equivalent in Fossil is: |
| 249 | 249 | |
| 250 | - cd long-established-project | |
| 251 | - fossil init .fsl | |
| 252 | - fossil open --force .fsl | |
| 253 | - fossil add * | |
| 254 | - fossil ci -m "Initial commit of project." | |
| 250 | + cd long-established-project | |
| 251 | + fossil init .fsl | |
| 252 | + fossil open --force .fsl | |
| 253 | + fossil add * | |
| 254 | + fossil ci -m "Initial commit of project." | |
| 255 | 255 | |
| 256 | 256 | Note that unlike in Git, you can abbreviate the “`commit`” command in |
| 257 | 257 | Fossil as “`ci`” for compatibility with CVS, Subversion, etc. |
| 258 | 258 | |
| 259 | 259 | This creates a `.fsl` repo DB at the root of the project check-out to |
| @@ -316,19 +316,19 @@ | ||
| 316 | 316 | #### <a id="emu-log"></a> Emulating `git log` |
| 317 | 317 | |
| 318 | 318 | If you truly need a backwards-in-time-only view of history in Fossil to |
| 319 | 319 | emulate `git log`, this is as close as you can currently come: |
| 320 | 320 | |
| 321 | - fossil timeline parents current | |
| 321 | + fossil timeline parents current | |
| 322 | 322 | |
| 323 | 323 | Again, though, this isn’t restricted to a single branch, as `git log` |
| 324 | 324 | is. |
| 325 | 325 | |
| 326 | 326 | Another useful rough equivalent is: |
| 327 | 327 | |
| 328 | - git log --raw | |
| 329 | - fossil time -v | |
| 328 | + git log --raw | |
| 329 | + fossil time -v | |
| 330 | 330 | |
| 331 | 331 | This shows what changed in each version, though Fossil’s view is more a |
| 332 | 332 | summary than a list of raw changes. To dig deeper into single commits, |
| 333 | 333 | you can use Fossil’s [`info` command][infoc] or its [`/info` view][infow]. |
| 334 | 334 | |
| @@ -344,33 +344,33 @@ | ||
| 344 | 344 | Though there is no `fossil whatchanged` command, the same sort of |
| 345 | 345 | information is available. For example, to pull the current changes from |
| 346 | 346 | the remote repository and then inspect them before updating the local |
| 347 | 347 | working directory, you might say this in Git: |
| 348 | 348 | |
| 349 | - git fetch | |
| 350 | - git whatchanged ..@{u} | |
| 349 | + git fetch | |
| 350 | + git whatchanged ..@{u} | |
| 351 | 351 | |
| 352 | 352 | …which you can approximate in Fossil as: |
| 353 | 353 | |
| 354 | - fossil pull | |
| 355 | - fossil up -n | |
| 356 | - fossil diff --from tip | |
| 354 | + fossil pull | |
| 355 | + fossil up -n | |
| 356 | + fossil diff --from tip | |
| 357 | 357 | |
| 358 | 358 | To invert the `diff` to show a more natural patch, the command needs to |
| 359 | 359 | be a bit more complicated, since you can’t currently give `--to` |
| 360 | 360 | without `--from`. |
| 361 | 361 | |
| 362 | - fossil diff --from current --to tip | |
| 362 | + fossil diff --from current --to tip | |
| 363 | 363 | |
| 364 | 364 | Rather than use the “dry run” form of [the `update` command][up], you can |
| 365 | 365 | say: |
| 366 | 366 | |
| 367 | - fossil timeline after current | |
| 367 | + fossil timeline after current | |
| 368 | 368 | |
| 369 | 369 | …or if you want to restrict the output to the current branch: |
| 370 | 370 | |
| 371 | - fossil timeline descendants current | |
| 371 | + fossil timeline descendants current | |
| 372 | 372 | |
| 373 | 373 | |
| 374 | 374 | #### <a id="ckin-names"></a> Symbolic Check-In Names |
| 375 | 375 | |
| 376 | 376 | Note the use of [human-readable symbolic version names][scin] in Fossil |
| @@ -377,42 +377,42 @@ | ||
| 377 | 377 | rather than [Git’s cryptic notations][gcn]. |
| 378 | 378 | |
| 379 | 379 | For a more dramatic example of this, let us ask Git, “What changed since the |
| 380 | 380 | beginning of last month?” being October 2020 as I write this: |
| 381 | 381 | |
| 382 | - git log master@{2020-10-01}..HEAD | |
| 382 | + git log master@{2020-10-01}..HEAD | |
| 383 | 383 | |
| 384 | 384 | That’s rather obscure! Fossil answers the same question with a simpler |
| 385 | 385 | command: |
| 386 | 386 | |
| 387 | - fossil timeline after 2020-10-01 | |
| 387 | + fossil timeline after 2020-10-01 | |
| 388 | 388 | |
| 389 | 389 | You may need to add `-n 0` to bypass the default output limit of |
| 390 | 390 | `fossil timeline`, 20 entries. Without that, this command reads |
| 391 | 391 | almost like English. |
| 392 | 392 | |
| 393 | 393 | Some Git users like to write commands like the above so: |
| 394 | 394 | |
| 395 | - git log @{2020-10-01}..@ | |
| 395 | + git log @{2020-10-01}..@ | |
| 396 | 396 | |
| 397 | 397 | Is that better? “@” now means two different things: an at-time reference |
| 398 | 398 | and a shortcut for `HEAD`! |
| 399 | 399 | |
| 400 | 400 | If you are one of those that like short commands, Fossil’s method is |
| 401 | 401 | less cryptic: it lets you shorten words in most cases up to the point |
| 402 | 402 | that they become ambiguous. For example, you may abbreviate the last |
| 403 | 403 | `fossil` command in the prior section: |
| 404 | 404 | |
| 405 | - fossil tim d c | |
| 405 | + fossil tim d c | |
| 406 | 406 | |
| 407 | 407 | …beyond which the `timeline` command becomes ambiguous with `ticket`. |
| 408 | 408 | |
| 409 | 409 | Some Fossil users employ shell aliases, symlinks, or scripts to shorten |
| 410 | 410 | the command still further: |
| 411 | 411 | |
| 412 | - alias f=fossil | |
| 413 | - f tim d c | |
| 412 | + alias f=fossil | |
| 413 | + f tim d c | |
| 414 | 414 | |
| 415 | 415 | Granted, that’s rather obscure, but you you can also choose something |
| 416 | 416 | intermediate like “`f time desc curr`”, which is reasonably clear. |
| 417 | 417 | |
| 418 | 418 | [35pct]: https://www.sqlite.org/fasterthanfs.html |
| @@ -468,11 +468,11 @@ | ||
| 468 | 468 | automatically. There is no need for the "-a" option as with Git. |
| 469 | 469 | |
| 470 | 470 | If you only want to commit _some_ of the changes, list the names |
| 471 | 471 | of the files or directories you want to commit as arguments, like this: |
| 472 | 472 | |
| 473 | - fossil commit src/feature.c doc/feature.md examples/feature | |
| 473 | + fossil commit src/feature.c doc/feature.md examples/feature | |
| 474 | 474 | |
| 475 | 475 | Note that the last element is a directory name, meaning “any changed |
| 476 | 476 | file under the `examples/feature` directory.” |
| 477 | 477 | |
| 478 | 478 | Although there are currently no |
| @@ -482,12 +482,12 @@ | ||
| 482 | 482 | running it through [Patchouli]. |
| 483 | 483 | |
| 484 | 484 | Rather than use `fossil diff -i` to produce such a patch, a safer and |
| 485 | 485 | more idiomatic method would be: |
| 486 | 486 | |
| 487 | - fossil stash save -m 'my big ball-o-hackage' | |
| 488 | - fossil stash diff > my-changes.patch | |
| 487 | + fossil stash save -m 'my big ball-o-hackage' | |
| 488 | + fossil stash diff > my-changes.patch | |
| 489 | 489 | |
| 490 | 490 | That stores your changes in the stash, then lets you operate on a copy |
| 491 | 491 | of that patch. Each time you re-run the second command, it will take the |
| 492 | 492 | current state of the working directory into account to produce a |
| 493 | 493 | potentially different patch, likely smaller because it leaves out patch |
| @@ -526,30 +526,30 @@ | ||
| 526 | 526 | ## Create Branches at Point of Need, Rather Than Ahead of Need |
| 527 | 527 | |
| 528 | 528 | Fossil prefers that you create new branches as part of the first commit |
| 529 | 529 | on that branch: |
| 530 | 530 | |
| 531 | - fossil commit --branch my-branch | |
| 531 | + fossil commit --branch my-branch | |
| 532 | 532 | |
| 533 | 533 | If that commit is successful, your local check-out directory is then |
| 534 | 534 | switched to the tip of that branch, so subsequent commits don’t need the |
| 535 | 535 | “`--branch`” option. You simply say `fossil commit` again to continue |
| 536 | 536 | adding commits to the tip of that branch. |
| 537 | 537 | |
| 538 | 538 | To switch back to the parent branch, say something like: |
| 539 | 539 | |
| 540 | - fossil update trunk | |
| 540 | + fossil update trunk | |
| 541 | 541 | |
| 542 | 542 | (This is approximately equivalent to `git checkout master`.) |
| 543 | 543 | |
| 544 | 544 | Fossil does also support the Git style, creating the branch ahead of |
| 545 | 545 | need: |
| 546 | 546 | |
| 547 | - fossil branch new my-branch | |
| 548 | - fossil up my-branch | |
| 549 | - ...work on first commit... | |
| 550 | - fossil commit | |
| 547 | + fossil branch new my-branch | |
| 548 | + fossil up my-branch | |
| 549 | + ...work on first commit... | |
| 550 | + fossil commit | |
| 551 | 551 | |
| 552 | 552 | This is more verbose, giving the same overall effect though the initial |
| 553 | 553 | actions are inverted: create a new branch for the first commit, switch |
| 554 | 554 | the check-out directory to that branch, and make that first commit. As |
| 555 | 555 | above, subsequent commits are descendants of that initial branch commit. |
| @@ -558,11 +558,11 @@ | ||
| 558 | 558 | |
| 559 | 559 | Fossil also allows you to move a check-in to a different branch |
| 560 | 560 | *after* you commit it, using the "`fossil amend`" command. |
| 561 | 561 | For example: |
| 562 | 562 | |
| 563 | - fossil amend current --branch my-branch | |
| 563 | + fossil amend current --branch my-branch | |
| 564 | 564 | |
| 565 | 565 | This works by inserting a tag into the repository that causes the web UI |
| 566 | 566 | to relabel commits from that point forward with the new name. Like Git, |
| 567 | 567 | Fossil’s fundamental data structure is the interlinked DAG of commit |
| 568 | 568 | hashes; branch names are supplemental data for making it easier for the |
| @@ -591,15 +591,15 @@ | ||
| 591 | 591 | make them under this eventually-consistent design philosophy. |
| 592 | 592 | |
| 593 | 593 | Branch *names* sync automatically in Fossil, not just the |
| 594 | 594 | content of those branches. That means this common Git command: |
| 595 | 595 | |
| 596 | - git push origin master | |
| 596 | + git push origin master | |
| 597 | 597 | |
| 598 | 598 | …is simply this in Fossil: |
| 599 | 599 | |
| 600 | - fossil push | |
| 600 | + fossil push | |
| 601 | 601 | |
| 602 | 602 | Fossil doesn’t need to be told what to push or where to push it: it just |
| 603 | 603 | keeps using the same remote server URL you gave it last |
| 604 | 604 | until you [tell it to do something different][rem]. It pushes all |
| 605 | 605 | branches, not just one named local branch. |
| @@ -613,11 +613,11 @@ | ||
| 613 | 613 | |
| 614 | 614 | Fossil’s [autosync][wflow] feature, normally enabled, has no |
| 615 | 615 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 616 | 616 | it off: |
| 617 | 617 | |
| 618 | - fossil set autosync 0 | |
| 618 | + fossil set autosync 0 | |
| 619 | 619 | |
| 620 | 620 | Let’s say that you have a typical server-and-workstations model with two |
| 621 | 621 | working clones on different machines, that you have disabled autosync, |
| 622 | 622 | and that this common sequence then occurs: |
| 623 | 623 | |
| @@ -692,16 +692,16 @@ | ||
| 692 | 692 | by a colon. The simplified example above is also liable to become |
| 693 | 693 | confused by whitespace in file names.) |
| 694 | 694 | |
| 695 | 695 | |
| 696 | 696 | ``` |
| 697 | - $ repo=$(fossil status | grep ^repo | cut -f2 -d:) | |
| 698 | - $ url=$(fossil remote) | |
| 699 | - $ fossil close # Stop here and think if it warns you! | |
| 700 | - $ mv $repo ${repo}.old | |
| 701 | - $ fossil clone $url $repo | |
| 702 | - $ fossil open --force $repo | |
| 697 | +$ repo=$(fossil status | grep ^repo | cut -f2 -d:) | |
| 698 | +$ url=$(fossil remote) | |
| 699 | +$ fossil close # Stop here and think if it warns you! | |
| 700 | +$ mv $repo ${repo}.old | |
| 701 | +$ fossil clone $url $repo | |
| 702 | +$ fossil open --force $repo | |
| 703 | 703 | ``` |
| 704 | 704 | |
| 705 | 705 | What, then, should you as a Git transplant do instead when you find |
| 706 | 706 | yourself reaching for “`git reset`”? |
| 707 | 707 | |
| @@ -717,13 +717,13 @@ | ||
| 717 | 717 | sort of thing is unnecessary. |
| 718 | 718 | |
| 719 | 719 | Instead, Bob can say something like this: |
| 720 | 720 | |
| 721 | 721 | ``` |
| 722 | - fossil amend --branch MISTAKE --hide --close -m "mea culpa" tip | |
| 723 | - fossil up trunk | |
| 724 | - fossil push | |
| 722 | +fossil amend --branch MISTAKE --hide --close -m "mea culpa" tip | |
| 723 | +fossil up trunk | |
| 724 | +fossil push | |
| 725 | 725 | ``` |
| 726 | 726 | |
| 727 | 727 | Unlike in Git, the “`amend`” command doesn’t modify prior committed |
| 728 | 728 | artifacts. Bob’s first command doesn’t delete anything, merely tells |
| 729 | 729 | Fossil to hide his mistake from timeline views by inserting a few new |
| @@ -750,14 +750,14 @@ | ||
| 750 | 750 | marked the branch as closed will prevent that from going thru, cluing |
| 751 | 751 | Alice into what she needs to do to remedy the situation, but that merely |
| 752 | 752 | shows why it’s a better workflow if Alice makes the amendment herself: |
| 753 | 753 | |
| 754 | 754 | ``` |
| 755 | - fossil amend --branch MISTAKE --hide --close \ | |
| 756 | - -m "shunt Bob’s erroneous commit off" tip | |
| 757 | - fossil up trunk | |
| 758 | - fossil push | |
| 755 | +fossil amend --branch MISTAKE --hide --close \ | |
| 756 | + -m "shunt Bob’s erroneous commit off" tip | |
| 757 | +fossil up trunk | |
| 758 | +fossil push | |
| 759 | 759 | ``` |
| 760 | 760 | |
| 761 | 761 | Then she can fire off an email listing Bob’s assorted failings and go |
| 762 | 762 | about her work. This asynchronous workflow solves the problem without |
| 763 | 763 | requiring explicit coordination with Bob. When he gets his email, he can |
| @@ -834,18 +834,18 @@ | ||
| 834 | 834 | Nevertheless, there are multiple ways to get colorized diff output from |
| 835 | 835 | Fossil: |
| 836 | 836 | |
| 837 | 837 | * The most direct method is to delegate diff behavior back to Git: |
| 838 | 838 | |
| 839 | - fossil set --global diff-command 'git diff --no-index' | |
| 839 | + fossil set --global diff-command 'git diff --no-index' | |
| 840 | 840 | |
| 841 | 841 | The flag permits it to diff files that aren’t inside a Git repository. |
| 842 | 842 | |
| 843 | 843 | * Another method is to install [`colordiff`][cdiff] — included in |
| 844 | 844 | [many package systems][cdpkg] — then say: |
| 845 | 845 | |
| 846 | - fossil set --global diff-command 'colordiff -wu' | |
| 846 | + fossil set --global diff-command 'colordiff -wu' | |
| 847 | 847 | |
| 848 | 848 | Because this is unconditional, unlike `git diff --color=auto`, you |
| 849 | 849 | will then have to remember to add the `-i` option to `fossil diff` |
| 850 | 850 | commands when you want color disabled, such as when producing |
| 851 | 851 | `patch(1)` files or piping diff output to another command that |
| @@ -876,15 +876,15 @@ | ||
| 876 | 876 | functionality is present in Fossil under other commands: |
| 877 | 877 | |
| 878 | 878 | |
| 879 | 879 | #### <a id="patch"></a> Show a Patch for a Commit |
| 880 | 880 | |
| 881 | - git show -p COMMIT_ID | |
| 881 | + git show -p COMMIT_ID | |
| 882 | 882 | |
| 883 | 883 | …gives much the same output as |
| 884 | 884 | |
| 885 | - fossil diff --checkin COMMIT_ID | |
| 885 | + fossil diff --checkin COMMIT_ID | |
| 886 | 886 | |
| 887 | 887 | …only without the patch email header. Git comes out of the [LKML] world, |
| 888 | 888 | where emailing a patch is a normal thing to do. Fossil is [designed for |
| 889 | 889 | cohesive teams][devorg] where drive-by patches are rarer. |
| 890 | 890 | |
| @@ -893,32 +893,32 @@ | ||
| 893 | 893 | “`VERSION`” or “`NAME`” where this is allowed, since the version string |
| 894 | 894 | or name might not refer to a commit ID, but instead to a forum post, a |
| 895 | 895 | wiki document, etc. For instance, the following command answers the question “What did |
| 896 | 896 | I just commit?” |
| 897 | 897 | |
| 898 | - fossil diff --checkin tip | |
| 898 | + fossil diff --checkin tip | |
| 899 | 899 | |
| 900 | 900 | …or equivalently using a different symbolic commit name: |
| 901 | 901 | |
| 902 | - fossil diff --from prev | |
| 902 | + fossil diff --from prev | |
| 903 | 903 | |
| 904 | 904 | [devorg]: ./fossil-v-git.wiki#devorg |
| 905 | 905 | [LKML]: https://lkml.org/ |
| 906 | 906 | |
| 907 | 907 | |
| 908 | 908 | #### <a id="cmsg"></a> Show a Specific Commit Message |
| 909 | 909 | |
| 910 | - git show -s COMMIT_ID | |
| 910 | + git show -s COMMIT_ID | |
| 911 | 911 | |
| 912 | 912 | |
| 913 | 913 | …is |
| 914 | 914 | |
| 915 | - fossil time -n 1 COMMIT_ID | |
| 915 | + fossil time -n 1 COMMIT_ID | |
| 916 | 916 | |
| 917 | 917 | …or with a shorter, more obvious command, though with more verbose output: |
| 918 | 918 | |
| 919 | - fossil info COMMIT_ID | |
| 919 | + fossil info COMMIT_ID | |
| 920 | 920 | |
| 921 | 921 | The `fossil info` command isn’t otherwise a good equivalent to |
| 922 | 922 | `git show`; it just overlaps its functionality in some areas. Much of |
| 923 | 923 | what’s missing is present in the corresponding [`/info` web |
| 924 | 924 | view][infow], though. |
| @@ -927,17 +927,17 @@ | ||
| 927 | 927 | #### <a id="dstat"></a> Diff Statistics |
| 928 | 928 | |
| 929 | 929 | Fossil’s closest internal equivalent to commands like |
| 930 | 930 | `git show --stat` is: |
| 931 | 931 | |
| 932 | - fossil diff -i --from 2020-04-01 --numstat | |
| 932 | + fossil diff -i --from 2020-04-01 --numstat | |
| 933 | 933 | |
| 934 | 934 | The `--numstat` output is a bit cryptic, so we recommend delegating |
| 935 | 935 | this task to [the widely-available `diffstat` tool][dst], which gives |
| 936 | 936 | a histogram in its default output mode rather than bare integers: |
| 937 | 937 | |
| 938 | - fossil diff -i -v --from 2020-04-01 | diffstat | |
| 938 | + fossil diff -i -v --from 2020-04-01 | diffstat | |
| 939 | 939 | |
| 940 | 940 | We gave the `-i` flag in both cases to force Fossil to use its internal |
| 941 | 941 | diff implementation, bypassing [your local `diff-command` setting][dcset]. |
| 942 | 942 | The `--numstat` option has no effect when you have an external diff |
| 943 | 943 | command set, and some diff command alternatives like |
| @@ -999,19 +999,19 @@ | ||
| 999 | 999 | default: they do not actually rename or delete the files in your |
| 1000 | 1000 | check-out. |
| 1001 | 1001 | |
| 1002 | 1002 | If you don’t like that default, you can change it globally: |
| 1003 | 1003 | |
| 1004 | - fossil setting --global mv-rm-files 1 | |
| 1004 | + fossil setting --global mv-rm-files 1 | |
| 1005 | 1005 | |
| 1006 | 1006 | Now these commands behave like in Git in any Fossil repository where |
| 1007 | 1007 | this setting hasn’t been overridden locally. |
| 1008 | 1008 | |
| 1009 | 1009 | If you want to keep Fossil’s soft `mv/rm` behavior most of the time, you |
| 1010 | 1010 | can cast it away on a per-command basis: |
| 1011 | 1011 | |
| 1012 | - fossil mv --hard old-name new-name | |
| 1012 | + fossil mv --hard old-name new-name | |
| 1013 | 1013 | |
| 1014 | 1014 | [mv]: /help?cmd=mv |
| 1015 | 1015 | [rm]: /help?cmd=rm |
| 1016 | 1016 | |
| 1017 | 1017 | |
| @@ -1032,11 +1032,11 @@ | ||
| 1032 | 1032 | |
| 1033 | 1033 | My search engine’s first result for “git checkout by date” is [this |
| 1034 | 1034 | highly-upvoted accepted Stack Overflow answer][gcod]. The first command |
| 1035 | 1035 | it gives is based on Git’s [`rev-parse` feature][grp]: |
| 1036 | 1036 | |
| 1037 | - git checkout master@{2020-03-17} | |
| 1037 | + git checkout master@{2020-03-17} | |
| 1038 | 1038 | |
| 1039 | 1039 | There are a number of weaknesses in this command. From least to most |
| 1040 | 1040 | critical: |
| 1041 | 1041 | |
| 1042 | 1042 | 1. It’s a bit cryptic. Leave off the refname or punctuation, and it |
| @@ -1072,11 +1072,11 @@ | ||
| 1072 | 1072 | best case. |
| 1073 | 1073 | |
| 1074 | 1074 | That same Stack Overflow answer therefore goes on to recommend an |
| 1075 | 1075 | entirely different command: |
| 1076 | 1076 | |
| 1077 | - git checkout $(git rev-list -n 1 --first-parent --before="2020-03-17" master) | |
| 1077 | + git checkout $(git rev-list -n 1 --first-parent --before="2020-03-17" master) | |
| 1078 | 1078 | |
| 1079 | 1079 | We believe you get such answers to Git help requests in part |
| 1080 | 1080 | because of its lack of an always-up-to-date [index into its log](#log) and in |
| 1081 | 1081 | part because of its “small tools loosely joined” design philosophy. This |
| 1082 | 1082 | sort of command is therefore composed piece by piece: |
| @@ -1084,36 +1084,36 @@ | ||
| 1084 | 1084 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1085 | 1085 | |
| 1086 | 1086 | “Oh, I know, I’ll search the rev-list, which outputs commit IDs by |
| 1087 | 1087 | parsing the log backwards from `HEAD`! Easy!” |
| 1088 | 1088 | |
| 1089 | - git rev-list --before=2020-03-17 | |
| 1089 | + git rev-list --before=2020-03-17 | |
| 1090 | 1090 | |
| 1091 | 1091 | “Blast! Forgot the commit ID!” |
| 1092 | 1092 | |
| 1093 | - git rev-list --before=2020-03-17 master | |
| 1093 | + git rev-list --before=2020-03-17 master | |
| 1094 | 1094 | |
| 1095 | 1095 | “Double blast! It just spammed my terminal with revision IDs! I need to |
| 1096 | 1096 | limit it to the single closest match: |
| 1097 | 1097 | |
| 1098 | - git rev-list -n 1 --before=2020-03-17 master | |
| 1098 | + git rev-list -n 1 --before=2020-03-17 master | |
| 1099 | 1099 | |
| 1100 | 1100 | “Okay, it gives me a single revision ID now, but is it what I’m after? |
| 1101 | 1101 | Let’s take a look…” |
| 1102 | 1102 | |
| 1103 | - git show $(git rev-list -n 1 --before=2020-03-17 master) | |
| 1103 | + git show $(git rev-list -n 1 --before=2020-03-17 master) | |
| 1104 | 1104 | |
| 1105 | 1105 | “Oops, that’s giving me a merge commit, not what I want. |
| 1106 | 1106 | Off to search the web… Okay, it says I need to give either the |
| 1107 | 1107 | `--first-parent` or `--no-merges` flag to show only regular commits, |
| 1108 | 1108 | not merge-commits. Let’s try the first one:” |
| 1109 | 1109 | |
| 1110 | - git show $(git rev-list -n 1 --first-parent --before=2020-03-17 master) | |
| 1110 | + git show $(git rev-list -n 1 --first-parent --before=2020-03-17 master) | |
| 1111 | 1111 | |
| 1112 | 1112 | “Better. Let’s check it out:” |
| 1113 | 1113 | |
| 1114 | - git checkout $(git rev-list -n 1 --first-parent --before=2020-03-17 master) | |
| 1114 | + git checkout $(git rev-list -n 1 --first-parent --before=2020-03-17 master) | |
| 1115 | 1115 | |
| 1116 | 1116 | “Success, I guess?” |
| 1117 | 1117 | |
| 1118 | 1118 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1119 | 1119 | |
| @@ -1132,11 +1132,11 @@ | ||
| 1132 | 1132 | 17th of March, 2020. |
| 1133 | 1133 | |
| 1134 | 1134 | You may be asking with an exasperated huff, “What is your *point*, man?” |
| 1135 | 1135 | The point is that the equivalent in Fossil is simply: |
| 1136 | 1136 | |
| 1137 | - fossil up 2020-03-17 | |
| 1137 | + fossil up 2020-03-17 | |
| 1138 | 1138 | |
| 1139 | 1139 | …which will *always* give the commit closest to midnight UTC on the 17th |
| 1140 | 1140 | of March, 2020, no matter whether you do it on a fresh clone or a stale |
| 1141 | 1141 | one. The answer won’t shift about from one clone to the next or from |
| 1142 | 1142 | one local time of day to the next. We owe this reliability and stability |
| @@ -1181,13 +1181,13 @@ | ||
| 1181 | 1181 | #### Git Method |
| 1182 | 1182 | |
| 1183 | 1183 | We first need to clone the work repo down to our laptop, so we can work on it |
| 1184 | 1184 | at home: |
| 1185 | 1185 | |
| 1186 | - git clone https://dev-server.example.com/repo | |
| 1187 | - cd repo | |
| 1188 | - git remote rename origin work | |
| 1186 | + git clone https://dev-server.example.com/repo | |
| 1187 | + cd repo | |
| 1188 | + git remote rename origin work | |
| 1189 | 1189 | |
| 1190 | 1190 | The last command is optional, strictly speaking. We could continue to |
| 1191 | 1191 | use Git’s default name for the work repo’s origin — sensibly enough |
| 1192 | 1192 | called “`origin`” — but it makes later commands harder to understand, so |
| 1193 | 1193 | we rename it here. This will also make the parallel with Fossil easier |
| @@ -1194,12 +1194,12 @@ | ||
| 1194 | 1194 | to draw. |
| 1195 | 1195 | |
| 1196 | 1196 | The first time we go home after this, we have to reverse-clone the work |
| 1197 | 1197 | repo up to the NAS: |
| 1198 | 1198 | |
| 1199 | - ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' | |
| 1200 | - git push --all ssh://my-nas.local//SHARES/dayjob/repo.git | |
| 1199 | + ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' | |
| 1200 | + git push --all ssh://my-nas.local//SHARES/dayjob/repo.git | |
| 1201 | 1201 | |
| 1202 | 1202 | Realize that this is carefully optimized down to these two long |
| 1203 | 1203 | commands. In practice, we’d expect a user typing these commands by hand from memory |
| 1204 | 1204 | to need to give four or more commands here instead. |
| 1205 | 1205 | Packing the “`git init`” call into the “`ssh`” call is something more |
| @@ -1213,31 +1213,31 @@ | ||
| 1213 | 1213 | |
| 1214 | 1214 | Having navigated that little minefield, |
| 1215 | 1215 | we can tell Git that there is a second origin, a “home” repo in |
| 1216 | 1216 | addition to the named “work” repo we set up earlier: |
| 1217 | 1217 | |
| 1218 | - git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git | |
| 1219 | - git config master.remote home | |
| 1218 | + git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git | |
| 1219 | + git config master.remote home | |
| 1220 | 1220 | |
| 1221 | 1221 | We don’t have to push or pull because the remote repo is a complete |
| 1222 | 1222 | clone of the repo on the laptop at this point, so we can just get to |
| 1223 | 1223 | work now, committing along the way to get our work safely off-machine |
| 1224 | 1224 | and onto our home NAS, like so: |
| 1225 | 1225 | |
| 1226 | - git add | |
| 1227 | - git commit | |
| 1228 | - git push | |
| 1226 | + git add | |
| 1227 | + git commit | |
| 1228 | + git push | |
| 1229 | 1229 | |
| 1230 | 1230 | We didn’t need to give a remote name on the push because we told it the |
| 1231 | 1231 | new upstream is the home NAS earlier. |
| 1232 | 1232 | |
| 1233 | 1233 | Now Friday comes along, and one of your office-mates needs a feature |
| 1234 | 1234 | you’re working on. You agree to come into the office later that |
| 1235 | 1235 | afternoon to sync up via the dev server: |
| 1236 | 1236 | |
| 1237 | - git push work master # send your changes from home up | |
| 1238 | - git pull work master # get your coworkers’ changes | |
| 1237 | + git push work master # send your changes from home up | |
| 1238 | + git pull work master # get your coworkers’ changes | |
| 1239 | 1239 | |
| 1240 | 1240 | Alternately, we could add “`--set-upstream/-u work`” to the first |
| 1241 | 1241 | command if we were coming into work long enough to do several Git-based things, not just pop in and sync. |
| 1242 | 1242 | That would allow the second to be just “`git pull`”, but the cost is |
| 1243 | 1243 | that when returning home, you’d have to manually reset the upstream |
| @@ -1254,13 +1254,13 @@ | ||
| 1254 | 1254 | Now we’re going to do the same thing using Fossil, with |
| 1255 | 1255 | the commands arranged in blocks corresponding to those above for comparison. |
| 1256 | 1256 | |
| 1257 | 1257 | We start the same way, cloning the work repo down to the laptop: |
| 1258 | 1258 | |
| 1259 | - fossil clone https://dev-server.example.com/repo | |
| 1260 | - cd repo | |
| 1261 | - fossil remote add work https://dev-server.example.com/repo | |
| 1259 | + fossil clone https://dev-server.example.com/repo | |
| 1260 | + cd repo | |
| 1261 | + fossil remote add work https://dev-server.example.com/repo | |
| 1262 | 1262 | |
| 1263 | 1263 | We’ve chosen the new “`fossil clone URI`” syntax added in Fossil 2.14 rather than separate |
| 1264 | 1264 | `clone` and `open` commands to make the parallel with Git clearer. [See |
| 1265 | 1265 | above](#mwd) for more on that topic. |
| 1266 | 1266 | |
| @@ -1278,11 +1278,11 @@ | ||
| 1278 | 1278 | below. |
| 1279 | 1279 | |
| 1280 | 1280 | On first beginning to work from home, we reverse-clone the Fossil repo |
| 1281 | 1281 | up to the NAS: |
| 1282 | 1282 | |
| 1283 | - rsync repo.fossil my-nas.local:/SHARES/dayjob/ | |
| 1283 | + rsync repo.fossil my-nas.local:/SHARES/dayjob/ | |
| 1284 | 1284 | |
| 1285 | 1285 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 1286 | 1286 | relative to the tricky “`git init && git push`” sequence above. |
| 1287 | 1287 | Fossil’s alternative is almost impossible to get |
| 1288 | 1288 | wrong: copy this to that. *Done.* |
| @@ -1297,12 +1297,12 @@ | ||
| 1297 | 1297 | inherent in using `rsync` to clone a Git repo][grsync]. |
| 1298 | 1298 | |
| 1299 | 1299 | Now we set up the second remote, which is again simpler in the Fossil |
| 1300 | 1300 | case: |
| 1301 | 1301 | |
| 1302 | - fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil | |
| 1303 | - fossil remote home | |
| 1302 | + fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil | |
| 1303 | + fossil remote home | |
| 1304 | 1304 | |
| 1305 | 1305 | The first command is nearly identical to the Git version, but the second |
| 1306 | 1306 | is considerably simpler. And to be fair, you won’t find the |
| 1307 | 1307 | “`git config`” command above in all Git tutorials. The more common |
| 1308 | 1308 | alternative we found with web searches is even longer: |
| @@ -1309,21 +1309,21 @@ | ||
| 1309 | 1309 | “`git push --set-upstream home master`”. |
| 1310 | 1310 | |
| 1311 | 1311 | Where Fossil really wins is in the next step, making the initial commit |
| 1312 | 1312 | from home: |
| 1313 | 1313 | |
| 1314 | - fossil ci | |
| 1314 | + fossil ci | |
| 1315 | 1315 | |
| 1316 | 1316 | It’s one short command for Fossil instead of three for Git — or two if |
| 1317 | 1317 | you abbreviate it as “`git commit -a && git push`” — because of Fossil’s |
| 1318 | 1318 | [autosync] feature and deliberate omission of a |
| 1319 | 1319 | [staging feature](#staging). |
| 1320 | 1320 | |
| 1321 | 1321 | The “Friday afternoon sync-up” case is simpler, too: |
| 1322 | 1322 | |
| 1323 | - fossil remote work | |
| 1324 | - fossil sync | |
| 1323 | + fossil remote work | |
| 1324 | + fossil sync | |
| 1325 | 1325 | |
| 1326 | 1326 | Back at home, it’s simpler still: we may be able to do away with the second command, |
| 1327 | 1327 | saying just “`fossil remote home`” because the sync will happen as part |
| 1328 | 1328 | of the next commit, thanks once again to Fossil’s autosync feature. If |
| 1329 | 1329 | the working branch now has commits from other developers after syncing |
| 1330 | 1330 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -73,15 +73,15 @@ | |
| 73 | document][ckwf] to see the practical differences. |
| 74 | |
| 75 | There is one Git-specific detail we wish to add beyond what that |
| 76 | document already covers. This command: |
| 77 | |
| 78 | git checkout some-branch |
| 79 | |
| 80 | …is best given as: |
| 81 | |
| 82 | fossil update some-branch |
| 83 | |
| 84 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 85 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 86 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 87 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| @@ -109,11 +109,11 @@ | |
| 109 | |
| 110 | The `fossil pull` command is simply the reverse of |
| 111 | `fossil push`, so that `fossil sync` [is functionally equivalent |
| 112 | to](./sync.wiki#sync): |
| 113 | |
| 114 | fossil push ; fossil pull |
| 115 | |
| 116 | There is no implicit “and update the local working directory” step in Fossil’s |
| 117 | push, pull, or sync commands, as there is with `git pull`. |
| 118 | |
| 119 | Someone coming from the Git perspective may perceive that `fossil up` |
| @@ -180,29 +180,29 @@ | |
| 180 | check-out directories][mcw] with Git. |
| 181 | |
| 182 | The old way is to simply symlink the `.git` directory between working |
| 183 | trees: |
| 184 | |
| 185 | mkdir ../foo-branch |
| 186 | ln -s ../actual-clone-dir/.git . |
| 187 | git checkout foo-branch |
| 188 | |
| 189 | The symlink trick has a number of problems, the largest being that |
| 190 | symlinks weren’t available on Windows until Vista, and until the Windows |
| 191 | 10 Creators Update was released in spring of 2017, you had to be an |
| 192 | Administrator to use the feature besides. ([Source][wsyml]) Git 2.5 solved |
| 193 | this problem back when Windows XP was Microsoft’s current offering |
| 194 | by adding the `git-worktree` command: |
| 195 | |
| 196 | git worktree add ../foo-branch foo-branch |
| 197 | cd ../foo-branch |
| 198 | |
| 199 | That is approximately equivalent to this in Fossil: |
| 200 | |
| 201 | mkdir ../foo-branch |
| 202 | cd ../foo-branch |
| 203 | fossil open /path/to/repo.fossil foo-branch |
| 204 | |
| 205 | The Fossil alternative is wordier, but since this tends to be one-time setup, |
| 206 | not something you do everyday, the overhead is insignificant. This author keeps a “scratch” check-out |
| 207 | for cases where it’s inappropriate to reuse the “trunk” check-out, |
| 208 | isolating all of my expedient switch-in-place actions to that one |
| @@ -211,20 +211,20 @@ | |
| 211 | up, I rarely pay the cost of these wordier commands. |
| 212 | |
| 213 | That then leads us to the closest equivalent in Git to [closing a Fossil |
| 214 | check-out](#close): |
| 215 | |
| 216 | git worktree remove . |
| 217 | |
| 218 | Note, however, that unlike `fossil close`, once the Git command |
| 219 | determines that there are no uncommitted changes, it blows away all of |
| 220 | the checked-out files! Fossil’s alternative is shorter, easier to |
| 221 | remember, and safer. |
| 222 | |
| 223 | There’s another way to get Fossil-like separate worktrees in Git: |
| 224 | |
| 225 | git clone --separate-git-dir repo.git https://example.com/repo |
| 226 | |
| 227 | This allows you to have your Git repository directory entirely separate |
| 228 | from your working tree, with `.git` in the check-out directory being a |
| 229 | file that points to `../repo.git`, in this example. |
| 230 | |
| @@ -238,22 +238,22 @@ | |
| 238 | from working directory creates in practice, consider this common Git “init in place” |
| 239 | method for creating a new repository from an existing tree of files, |
| 240 | perhaps because you are placing that project under version control for |
| 241 | the first time: |
| 242 | |
| 243 | cd long-established-project |
| 244 | git init |
| 245 | git add * |
| 246 | git commit -m "Initial commit of project." |
| 247 | |
| 248 | The closest equivalent in Fossil is: |
| 249 | |
| 250 | cd long-established-project |
| 251 | fossil init .fsl |
| 252 | fossil open --force .fsl |
| 253 | fossil add * |
| 254 | fossil ci -m "Initial commit of project." |
| 255 | |
| 256 | Note that unlike in Git, you can abbreviate the “`commit`” command in |
| 257 | Fossil as “`ci`” for compatibility with CVS, Subversion, etc. |
| 258 | |
| 259 | This creates a `.fsl` repo DB at the root of the project check-out to |
| @@ -316,19 +316,19 @@ | |
| 316 | #### <a id="emu-log"></a> Emulating `git log` |
| 317 | |
| 318 | If you truly need a backwards-in-time-only view of history in Fossil to |
| 319 | emulate `git log`, this is as close as you can currently come: |
| 320 | |
| 321 | fossil timeline parents current |
| 322 | |
| 323 | Again, though, this isn’t restricted to a single branch, as `git log` |
| 324 | is. |
| 325 | |
| 326 | Another useful rough equivalent is: |
| 327 | |
| 328 | git log --raw |
| 329 | fossil time -v |
| 330 | |
| 331 | This shows what changed in each version, though Fossil’s view is more a |
| 332 | summary than a list of raw changes. To dig deeper into single commits, |
| 333 | you can use Fossil’s [`info` command][infoc] or its [`/info` view][infow]. |
| 334 | |
| @@ -344,33 +344,33 @@ | |
| 344 | Though there is no `fossil whatchanged` command, the same sort of |
| 345 | information is available. For example, to pull the current changes from |
| 346 | the remote repository and then inspect them before updating the local |
| 347 | working directory, you might say this in Git: |
| 348 | |
| 349 | git fetch |
| 350 | git whatchanged ..@{u} |
| 351 | |
| 352 | …which you can approximate in Fossil as: |
| 353 | |
| 354 | fossil pull |
| 355 | fossil up -n |
| 356 | fossil diff --from tip |
| 357 | |
| 358 | To invert the `diff` to show a more natural patch, the command needs to |
| 359 | be a bit more complicated, since you can’t currently give `--to` |
| 360 | without `--from`. |
| 361 | |
| 362 | fossil diff --from current --to tip |
| 363 | |
| 364 | Rather than use the “dry run” form of [the `update` command][up], you can |
| 365 | say: |
| 366 | |
| 367 | fossil timeline after current |
| 368 | |
| 369 | …or if you want to restrict the output to the current branch: |
| 370 | |
| 371 | fossil timeline descendants current |
| 372 | |
| 373 | |
| 374 | #### <a id="ckin-names"></a> Symbolic Check-In Names |
| 375 | |
| 376 | Note the use of [human-readable symbolic version names][scin] in Fossil |
| @@ -377,42 +377,42 @@ | |
| 377 | rather than [Git’s cryptic notations][gcn]. |
| 378 | |
| 379 | For a more dramatic example of this, let us ask Git, “What changed since the |
| 380 | beginning of last month?” being October 2020 as I write this: |
| 381 | |
| 382 | git log master@{2020-10-01}..HEAD |
| 383 | |
| 384 | That’s rather obscure! Fossil answers the same question with a simpler |
| 385 | command: |
| 386 | |
| 387 | fossil timeline after 2020-10-01 |
| 388 | |
| 389 | You may need to add `-n 0` to bypass the default output limit of |
| 390 | `fossil timeline`, 20 entries. Without that, this command reads |
| 391 | almost like English. |
| 392 | |
| 393 | Some Git users like to write commands like the above so: |
| 394 | |
| 395 | git log @{2020-10-01}..@ |
| 396 | |
| 397 | Is that better? “@” now means two different things: an at-time reference |
| 398 | and a shortcut for `HEAD`! |
| 399 | |
| 400 | If you are one of those that like short commands, Fossil’s method is |
| 401 | less cryptic: it lets you shorten words in most cases up to the point |
| 402 | that they become ambiguous. For example, you may abbreviate the last |
| 403 | `fossil` command in the prior section: |
| 404 | |
| 405 | fossil tim d c |
| 406 | |
| 407 | …beyond which the `timeline` command becomes ambiguous with `ticket`. |
| 408 | |
| 409 | Some Fossil users employ shell aliases, symlinks, or scripts to shorten |
| 410 | the command still further: |
| 411 | |
| 412 | alias f=fossil |
| 413 | f tim d c |
| 414 | |
| 415 | Granted, that’s rather obscure, but you you can also choose something |
| 416 | intermediate like “`f time desc curr`”, which is reasonably clear. |
| 417 | |
| 418 | [35pct]: https://www.sqlite.org/fasterthanfs.html |
| @@ -468,11 +468,11 @@ | |
| 468 | automatically. There is no need for the "-a" option as with Git. |
| 469 | |
| 470 | If you only want to commit _some_ of the changes, list the names |
| 471 | of the files or directories you want to commit as arguments, like this: |
| 472 | |
| 473 | fossil commit src/feature.c doc/feature.md examples/feature |
| 474 | |
| 475 | Note that the last element is a directory name, meaning “any changed |
| 476 | file under the `examples/feature` directory.” |
| 477 | |
| 478 | Although there are currently no |
| @@ -482,12 +482,12 @@ | |
| 482 | running it through [Patchouli]. |
| 483 | |
| 484 | Rather than use `fossil diff -i` to produce such a patch, a safer and |
| 485 | more idiomatic method would be: |
| 486 | |
| 487 | fossil stash save -m 'my big ball-o-hackage' |
| 488 | fossil stash diff > my-changes.patch |
| 489 | |
| 490 | That stores your changes in the stash, then lets you operate on a copy |
| 491 | of that patch. Each time you re-run the second command, it will take the |
| 492 | current state of the working directory into account to produce a |
| 493 | potentially different patch, likely smaller because it leaves out patch |
| @@ -526,30 +526,30 @@ | |
| 526 | ## Create Branches at Point of Need, Rather Than Ahead of Need |
| 527 | |
| 528 | Fossil prefers that you create new branches as part of the first commit |
| 529 | on that branch: |
| 530 | |
| 531 | fossil commit --branch my-branch |
| 532 | |
| 533 | If that commit is successful, your local check-out directory is then |
| 534 | switched to the tip of that branch, so subsequent commits don’t need the |
| 535 | “`--branch`” option. You simply say `fossil commit` again to continue |
| 536 | adding commits to the tip of that branch. |
| 537 | |
| 538 | To switch back to the parent branch, say something like: |
| 539 | |
| 540 | fossil update trunk |
| 541 | |
| 542 | (This is approximately equivalent to `git checkout master`.) |
| 543 | |
| 544 | Fossil does also support the Git style, creating the branch ahead of |
| 545 | need: |
| 546 | |
| 547 | fossil branch new my-branch |
| 548 | fossil up my-branch |
| 549 | ...work on first commit... |
| 550 | fossil commit |
| 551 | |
| 552 | This is more verbose, giving the same overall effect though the initial |
| 553 | actions are inverted: create a new branch for the first commit, switch |
| 554 | the check-out directory to that branch, and make that first commit. As |
| 555 | above, subsequent commits are descendants of that initial branch commit. |
| @@ -558,11 +558,11 @@ | |
| 558 | |
| 559 | Fossil also allows you to move a check-in to a different branch |
| 560 | *after* you commit it, using the "`fossil amend`" command. |
| 561 | For example: |
| 562 | |
| 563 | fossil amend current --branch my-branch |
| 564 | |
| 565 | This works by inserting a tag into the repository that causes the web UI |
| 566 | to relabel commits from that point forward with the new name. Like Git, |
| 567 | Fossil’s fundamental data structure is the interlinked DAG of commit |
| 568 | hashes; branch names are supplemental data for making it easier for the |
| @@ -591,15 +591,15 @@ | |
| 591 | make them under this eventually-consistent design philosophy. |
| 592 | |
| 593 | Branch *names* sync automatically in Fossil, not just the |
| 594 | content of those branches. That means this common Git command: |
| 595 | |
| 596 | git push origin master |
| 597 | |
| 598 | …is simply this in Fossil: |
| 599 | |
| 600 | fossil push |
| 601 | |
| 602 | Fossil doesn’t need to be told what to push or where to push it: it just |
| 603 | keeps using the same remote server URL you gave it last |
| 604 | until you [tell it to do something different][rem]. It pushes all |
| 605 | branches, not just one named local branch. |
| @@ -613,11 +613,11 @@ | |
| 613 | |
| 614 | Fossil’s [autosync][wflow] feature, normally enabled, has no |
| 615 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 616 | it off: |
| 617 | |
| 618 | fossil set autosync 0 |
| 619 | |
| 620 | Let’s say that you have a typical server-and-workstations model with two |
| 621 | working clones on different machines, that you have disabled autosync, |
| 622 | and that this common sequence then occurs: |
| 623 | |
| @@ -692,16 +692,16 @@ | |
| 692 | by a colon. The simplified example above is also liable to become |
| 693 | confused by whitespace in file names.) |
| 694 | |
| 695 | |
| 696 | ``` |
| 697 | $ repo=$(fossil status | grep ^repo | cut -f2 -d:) |
| 698 | $ url=$(fossil remote) |
| 699 | $ fossil close # Stop here and think if it warns you! |
| 700 | $ mv $repo ${repo}.old |
| 701 | $ fossil clone $url $repo |
| 702 | $ fossil open --force $repo |
| 703 | ``` |
| 704 | |
| 705 | What, then, should you as a Git transplant do instead when you find |
| 706 | yourself reaching for “`git reset`”? |
| 707 | |
| @@ -717,13 +717,13 @@ | |
| 717 | sort of thing is unnecessary. |
| 718 | |
| 719 | Instead, Bob can say something like this: |
| 720 | |
| 721 | ``` |
| 722 | fossil amend --branch MISTAKE --hide --close -m "mea culpa" tip |
| 723 | fossil up trunk |
| 724 | fossil push |
| 725 | ``` |
| 726 | |
| 727 | Unlike in Git, the “`amend`” command doesn’t modify prior committed |
| 728 | artifacts. Bob’s first command doesn’t delete anything, merely tells |
| 729 | Fossil to hide his mistake from timeline views by inserting a few new |
| @@ -750,14 +750,14 @@ | |
| 750 | marked the branch as closed will prevent that from going thru, cluing |
| 751 | Alice into what she needs to do to remedy the situation, but that merely |
| 752 | shows why it’s a better workflow if Alice makes the amendment herself: |
| 753 | |
| 754 | ``` |
| 755 | fossil amend --branch MISTAKE --hide --close \ |
| 756 | -m "shunt Bob’s erroneous commit off" tip |
| 757 | fossil up trunk |
| 758 | fossil push |
| 759 | ``` |
| 760 | |
| 761 | Then she can fire off an email listing Bob’s assorted failings and go |
| 762 | about her work. This asynchronous workflow solves the problem without |
| 763 | requiring explicit coordination with Bob. When he gets his email, he can |
| @@ -834,18 +834,18 @@ | |
| 834 | Nevertheless, there are multiple ways to get colorized diff output from |
| 835 | Fossil: |
| 836 | |
| 837 | * The most direct method is to delegate diff behavior back to Git: |
| 838 | |
| 839 | fossil set --global diff-command 'git diff --no-index' |
| 840 | |
| 841 | The flag permits it to diff files that aren’t inside a Git repository. |
| 842 | |
| 843 | * Another method is to install [`colordiff`][cdiff] — included in |
| 844 | [many package systems][cdpkg] — then say: |
| 845 | |
| 846 | fossil set --global diff-command 'colordiff -wu' |
| 847 | |
| 848 | Because this is unconditional, unlike `git diff --color=auto`, you |
| 849 | will then have to remember to add the `-i` option to `fossil diff` |
| 850 | commands when you want color disabled, such as when producing |
| 851 | `patch(1)` files or piping diff output to another command that |
| @@ -876,15 +876,15 @@ | |
| 876 | functionality is present in Fossil under other commands: |
| 877 | |
| 878 | |
| 879 | #### <a id="patch"></a> Show a Patch for a Commit |
| 880 | |
| 881 | git show -p COMMIT_ID |
| 882 | |
| 883 | …gives much the same output as |
| 884 | |
| 885 | fossil diff --checkin COMMIT_ID |
| 886 | |
| 887 | …only without the patch email header. Git comes out of the [LKML] world, |
| 888 | where emailing a patch is a normal thing to do. Fossil is [designed for |
| 889 | cohesive teams][devorg] where drive-by patches are rarer. |
| 890 | |
| @@ -893,32 +893,32 @@ | |
| 893 | “`VERSION`” or “`NAME`” where this is allowed, since the version string |
| 894 | or name might not refer to a commit ID, but instead to a forum post, a |
| 895 | wiki document, etc. For instance, the following command answers the question “What did |
| 896 | I just commit?” |
| 897 | |
| 898 | fossil diff --checkin tip |
| 899 | |
| 900 | …or equivalently using a different symbolic commit name: |
| 901 | |
| 902 | fossil diff --from prev |
| 903 | |
| 904 | [devorg]: ./fossil-v-git.wiki#devorg |
| 905 | [LKML]: https://lkml.org/ |
| 906 | |
| 907 | |
| 908 | #### <a id="cmsg"></a> Show a Specific Commit Message |
| 909 | |
| 910 | git show -s COMMIT_ID |
| 911 | |
| 912 | |
| 913 | …is |
| 914 | |
| 915 | fossil time -n 1 COMMIT_ID |
| 916 | |
| 917 | …or with a shorter, more obvious command, though with more verbose output: |
| 918 | |
| 919 | fossil info COMMIT_ID |
| 920 | |
| 921 | The `fossil info` command isn’t otherwise a good equivalent to |
| 922 | `git show`; it just overlaps its functionality in some areas. Much of |
| 923 | what’s missing is present in the corresponding [`/info` web |
| 924 | view][infow], though. |
| @@ -927,17 +927,17 @@ | |
| 927 | #### <a id="dstat"></a> Diff Statistics |
| 928 | |
| 929 | Fossil’s closest internal equivalent to commands like |
| 930 | `git show --stat` is: |
| 931 | |
| 932 | fossil diff -i --from 2020-04-01 --numstat |
| 933 | |
| 934 | The `--numstat` output is a bit cryptic, so we recommend delegating |
| 935 | this task to [the widely-available `diffstat` tool][dst], which gives |
| 936 | a histogram in its default output mode rather than bare integers: |
| 937 | |
| 938 | fossil diff -i -v --from 2020-04-01 | diffstat |
| 939 | |
| 940 | We gave the `-i` flag in both cases to force Fossil to use its internal |
| 941 | diff implementation, bypassing [your local `diff-command` setting][dcset]. |
| 942 | The `--numstat` option has no effect when you have an external diff |
| 943 | command set, and some diff command alternatives like |
| @@ -999,19 +999,19 @@ | |
| 999 | default: they do not actually rename or delete the files in your |
| 1000 | check-out. |
| 1001 | |
| 1002 | If you don’t like that default, you can change it globally: |
| 1003 | |
| 1004 | fossil setting --global mv-rm-files 1 |
| 1005 | |
| 1006 | Now these commands behave like in Git in any Fossil repository where |
| 1007 | this setting hasn’t been overridden locally. |
| 1008 | |
| 1009 | If you want to keep Fossil’s soft `mv/rm` behavior most of the time, you |
| 1010 | can cast it away on a per-command basis: |
| 1011 | |
| 1012 | fossil mv --hard old-name new-name |
| 1013 | |
| 1014 | [mv]: /help?cmd=mv |
| 1015 | [rm]: /help?cmd=rm |
| 1016 | |
| 1017 | |
| @@ -1032,11 +1032,11 @@ | |
| 1032 | |
| 1033 | My search engine’s first result for “git checkout by date” is [this |
| 1034 | highly-upvoted accepted Stack Overflow answer][gcod]. The first command |
| 1035 | it gives is based on Git’s [`rev-parse` feature][grp]: |
| 1036 | |
| 1037 | git checkout master@{2020-03-17} |
| 1038 | |
| 1039 | There are a number of weaknesses in this command. From least to most |
| 1040 | critical: |
| 1041 | |
| 1042 | 1. It’s a bit cryptic. Leave off the refname or punctuation, and it |
| @@ -1072,11 +1072,11 @@ | |
| 1072 | best case. |
| 1073 | |
| 1074 | That same Stack Overflow answer therefore goes on to recommend an |
| 1075 | entirely different command: |
| 1076 | |
| 1077 | git checkout $(git rev-list -n 1 --first-parent --before="2020-03-17" master) |
| 1078 | |
| 1079 | We believe you get such answers to Git help requests in part |
| 1080 | because of its lack of an always-up-to-date [index into its log](#log) and in |
| 1081 | part because of its “small tools loosely joined” design philosophy. This |
| 1082 | sort of command is therefore composed piece by piece: |
| @@ -1084,36 +1084,36 @@ | |
| 1084 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1085 | |
| 1086 | “Oh, I know, I’ll search the rev-list, which outputs commit IDs by |
| 1087 | parsing the log backwards from `HEAD`! Easy!” |
| 1088 | |
| 1089 | git rev-list --before=2020-03-17 |
| 1090 | |
| 1091 | “Blast! Forgot the commit ID!” |
| 1092 | |
| 1093 | git rev-list --before=2020-03-17 master |
| 1094 | |
| 1095 | “Double blast! It just spammed my terminal with revision IDs! I need to |
| 1096 | limit it to the single closest match: |
| 1097 | |
| 1098 | git rev-list -n 1 --before=2020-03-17 master |
| 1099 | |
| 1100 | “Okay, it gives me a single revision ID now, but is it what I’m after? |
| 1101 | Let’s take a look…” |
| 1102 | |
| 1103 | git show $(git rev-list -n 1 --before=2020-03-17 master) |
| 1104 | |
| 1105 | “Oops, that’s giving me a merge commit, not what I want. |
| 1106 | Off to search the web… Okay, it says I need to give either the |
| 1107 | `--first-parent` or `--no-merges` flag to show only regular commits, |
| 1108 | not merge-commits. Let’s try the first one:” |
| 1109 | |
| 1110 | git show $(git rev-list -n 1 --first-parent --before=2020-03-17 master) |
| 1111 | |
| 1112 | “Better. Let’s check it out:” |
| 1113 | |
| 1114 | git checkout $(git rev-list -n 1 --first-parent --before=2020-03-17 master) |
| 1115 | |
| 1116 | “Success, I guess?” |
| 1117 | |
| 1118 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1119 | |
| @@ -1132,11 +1132,11 @@ | |
| 1132 | 17th of March, 2020. |
| 1133 | |
| 1134 | You may be asking with an exasperated huff, “What is your *point*, man?” |
| 1135 | The point is that the equivalent in Fossil is simply: |
| 1136 | |
| 1137 | fossil up 2020-03-17 |
| 1138 | |
| 1139 | …which will *always* give the commit closest to midnight UTC on the 17th |
| 1140 | of March, 2020, no matter whether you do it on a fresh clone or a stale |
| 1141 | one. The answer won’t shift about from one clone to the next or from |
| 1142 | one local time of day to the next. We owe this reliability and stability |
| @@ -1181,13 +1181,13 @@ | |
| 1181 | #### Git Method |
| 1182 | |
| 1183 | We first need to clone the work repo down to our laptop, so we can work on it |
| 1184 | at home: |
| 1185 | |
| 1186 | git clone https://dev-server.example.com/repo |
| 1187 | cd repo |
| 1188 | git remote rename origin work |
| 1189 | |
| 1190 | The last command is optional, strictly speaking. We could continue to |
| 1191 | use Git’s default name for the work repo’s origin — sensibly enough |
| 1192 | called “`origin`” — but it makes later commands harder to understand, so |
| 1193 | we rename it here. This will also make the parallel with Fossil easier |
| @@ -1194,12 +1194,12 @@ | |
| 1194 | to draw. |
| 1195 | |
| 1196 | The first time we go home after this, we have to reverse-clone the work |
| 1197 | repo up to the NAS: |
| 1198 | |
| 1199 | ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' |
| 1200 | git push --all ssh://my-nas.local//SHARES/dayjob/repo.git |
| 1201 | |
| 1202 | Realize that this is carefully optimized down to these two long |
| 1203 | commands. In practice, we’d expect a user typing these commands by hand from memory |
| 1204 | to need to give four or more commands here instead. |
| 1205 | Packing the “`git init`” call into the “`ssh`” call is something more |
| @@ -1213,31 +1213,31 @@ | |
| 1213 | |
| 1214 | Having navigated that little minefield, |
| 1215 | we can tell Git that there is a second origin, a “home” repo in |
| 1216 | addition to the named “work” repo we set up earlier: |
| 1217 | |
| 1218 | git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git |
| 1219 | git config master.remote home |
| 1220 | |
| 1221 | We don’t have to push or pull because the remote repo is a complete |
| 1222 | clone of the repo on the laptop at this point, so we can just get to |
| 1223 | work now, committing along the way to get our work safely off-machine |
| 1224 | and onto our home NAS, like so: |
| 1225 | |
| 1226 | git add |
| 1227 | git commit |
| 1228 | git push |
| 1229 | |
| 1230 | We didn’t need to give a remote name on the push because we told it the |
| 1231 | new upstream is the home NAS earlier. |
| 1232 | |
| 1233 | Now Friday comes along, and one of your office-mates needs a feature |
| 1234 | you’re working on. You agree to come into the office later that |
| 1235 | afternoon to sync up via the dev server: |
| 1236 | |
| 1237 | git push work master # send your changes from home up |
| 1238 | git pull work master # get your coworkers’ changes |
| 1239 | |
| 1240 | Alternately, we could add “`--set-upstream/-u work`” to the first |
| 1241 | command if we were coming into work long enough to do several Git-based things, not just pop in and sync. |
| 1242 | That would allow the second to be just “`git pull`”, but the cost is |
| 1243 | that when returning home, you’d have to manually reset the upstream |
| @@ -1254,13 +1254,13 @@ | |
| 1254 | Now we’re going to do the same thing using Fossil, with |
| 1255 | the commands arranged in blocks corresponding to those above for comparison. |
| 1256 | |
| 1257 | We start the same way, cloning the work repo down to the laptop: |
| 1258 | |
| 1259 | fossil clone https://dev-server.example.com/repo |
| 1260 | cd repo |
| 1261 | fossil remote add work https://dev-server.example.com/repo |
| 1262 | |
| 1263 | We’ve chosen the new “`fossil clone URI`” syntax added in Fossil 2.14 rather than separate |
| 1264 | `clone` and `open` commands to make the parallel with Git clearer. [See |
| 1265 | above](#mwd) for more on that topic. |
| 1266 | |
| @@ -1278,11 +1278,11 @@ | |
| 1278 | below. |
| 1279 | |
| 1280 | On first beginning to work from home, we reverse-clone the Fossil repo |
| 1281 | up to the NAS: |
| 1282 | |
| 1283 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 1284 | |
| 1285 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 1286 | relative to the tricky “`git init && git push`” sequence above. |
| 1287 | Fossil’s alternative is almost impossible to get |
| 1288 | wrong: copy this to that. *Done.* |
| @@ -1297,12 +1297,12 @@ | |
| 1297 | inherent in using `rsync` to clone a Git repo][grsync]. |
| 1298 | |
| 1299 | Now we set up the second remote, which is again simpler in the Fossil |
| 1300 | case: |
| 1301 | |
| 1302 | fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil |
| 1303 | fossil remote home |
| 1304 | |
| 1305 | The first command is nearly identical to the Git version, but the second |
| 1306 | is considerably simpler. And to be fair, you won’t find the |
| 1307 | “`git config`” command above in all Git tutorials. The more common |
| 1308 | alternative we found with web searches is even longer: |
| @@ -1309,21 +1309,21 @@ | |
| 1309 | “`git push --set-upstream home master`”. |
| 1310 | |
| 1311 | Where Fossil really wins is in the next step, making the initial commit |
| 1312 | from home: |
| 1313 | |
| 1314 | fossil ci |
| 1315 | |
| 1316 | It’s one short command for Fossil instead of three for Git — or two if |
| 1317 | you abbreviate it as “`git commit -a && git push`” — because of Fossil’s |
| 1318 | [autosync] feature and deliberate omission of a |
| 1319 | [staging feature](#staging). |
| 1320 | |
| 1321 | The “Friday afternoon sync-up” case is simpler, too: |
| 1322 | |
| 1323 | fossil remote work |
| 1324 | fossil sync |
| 1325 | |
| 1326 | Back at home, it’s simpler still: we may be able to do away with the second command, |
| 1327 | saying just “`fossil remote home`” because the sync will happen as part |
| 1328 | of the next commit, thanks once again to Fossil’s autosync feature. If |
| 1329 | the working branch now has commits from other developers after syncing |
| 1330 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -73,15 +73,15 @@ | |
| 73 | document][ckwf] to see the practical differences. |
| 74 | |
| 75 | There is one Git-specific detail we wish to add beyond what that |
| 76 | document already covers. This command: |
| 77 | |
| 78 | git checkout some-branch |
| 79 | |
| 80 | …is best given as: |
| 81 | |
| 82 | fossil update some-branch |
| 83 | |
| 84 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 85 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 86 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 87 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| @@ -109,11 +109,11 @@ | |
| 109 | |
| 110 | The `fossil pull` command is simply the reverse of |
| 111 | `fossil push`, so that `fossil sync` [is functionally equivalent |
| 112 | to](./sync.wiki#sync): |
| 113 | |
| 114 | fossil push ; fossil pull |
| 115 | |
| 116 | There is no implicit “and update the local working directory” step in Fossil’s |
| 117 | push, pull, or sync commands, as there is with `git pull`. |
| 118 | |
| 119 | Someone coming from the Git perspective may perceive that `fossil up` |
| @@ -180,29 +180,29 @@ | |
| 180 | check-out directories][mcw] with Git. |
| 181 | |
| 182 | The old way is to simply symlink the `.git` directory between working |
| 183 | trees: |
| 184 | |
| 185 | mkdir ../foo-branch |
| 186 | ln -s ../actual-clone-dir/.git . |
| 187 | git checkout foo-branch |
| 188 | |
| 189 | The symlink trick has a number of problems, the largest being that |
| 190 | symlinks weren’t available on Windows until Vista, and until the Windows |
| 191 | 10 Creators Update was released in spring of 2017, you had to be an |
| 192 | Administrator to use the feature besides. ([Source][wsyml]) Git 2.5 solved |
| 193 | this problem back when Windows XP was Microsoft’s current offering |
| 194 | by adding the `git-worktree` command: |
| 195 | |
| 196 | git worktree add ../foo-branch foo-branch |
| 197 | cd ../foo-branch |
| 198 | |
| 199 | That is approximately equivalent to this in Fossil: |
| 200 | |
| 201 | mkdir ../foo-branch |
| 202 | cd ../foo-branch |
| 203 | fossil open /path/to/repo.fossil foo-branch |
| 204 | |
| 205 | The Fossil alternative is wordier, but since this tends to be one-time setup, |
| 206 | not something you do everyday, the overhead is insignificant. This author keeps a “scratch” check-out |
| 207 | for cases where it’s inappropriate to reuse the “trunk” check-out, |
| 208 | isolating all of my expedient switch-in-place actions to that one |
| @@ -211,20 +211,20 @@ | |
| 211 | up, I rarely pay the cost of these wordier commands. |
| 212 | |
| 213 | That then leads us to the closest equivalent in Git to [closing a Fossil |
| 214 | check-out](#close): |
| 215 | |
| 216 | git worktree remove . |
| 217 | |
| 218 | Note, however, that unlike `fossil close`, once the Git command |
| 219 | determines that there are no uncommitted changes, it blows away all of |
| 220 | the checked-out files! Fossil’s alternative is shorter, easier to |
| 221 | remember, and safer. |
| 222 | |
| 223 | There’s another way to get Fossil-like separate worktrees in Git: |
| 224 | |
| 225 | git clone --separate-git-dir repo.git https://example.com/repo |
| 226 | |
| 227 | This allows you to have your Git repository directory entirely separate |
| 228 | from your working tree, with `.git` in the check-out directory being a |
| 229 | file that points to `../repo.git`, in this example. |
| 230 | |
| @@ -238,22 +238,22 @@ | |
| 238 | from working directory creates in practice, consider this common Git “init in place” |
| 239 | method for creating a new repository from an existing tree of files, |
| 240 | perhaps because you are placing that project under version control for |
| 241 | the first time: |
| 242 | |
| 243 | cd long-established-project |
| 244 | git init |
| 245 | git add * |
| 246 | git commit -m "Initial commit of project." |
| 247 | |
| 248 | The closest equivalent in Fossil is: |
| 249 | |
| 250 | cd long-established-project |
| 251 | fossil init .fsl |
| 252 | fossil open --force .fsl |
| 253 | fossil add * |
| 254 | fossil ci -m "Initial commit of project." |
| 255 | |
| 256 | Note that unlike in Git, you can abbreviate the “`commit`” command in |
| 257 | Fossil as “`ci`” for compatibility with CVS, Subversion, etc. |
| 258 | |
| 259 | This creates a `.fsl` repo DB at the root of the project check-out to |
| @@ -316,19 +316,19 @@ | |
| 316 | #### <a id="emu-log"></a> Emulating `git log` |
| 317 | |
| 318 | If you truly need a backwards-in-time-only view of history in Fossil to |
| 319 | emulate `git log`, this is as close as you can currently come: |
| 320 | |
| 321 | fossil timeline parents current |
| 322 | |
| 323 | Again, though, this isn’t restricted to a single branch, as `git log` |
| 324 | is. |
| 325 | |
| 326 | Another useful rough equivalent is: |
| 327 | |
| 328 | git log --raw |
| 329 | fossil time -v |
| 330 | |
| 331 | This shows what changed in each version, though Fossil’s view is more a |
| 332 | summary than a list of raw changes. To dig deeper into single commits, |
| 333 | you can use Fossil’s [`info` command][infoc] or its [`/info` view][infow]. |
| 334 | |
| @@ -344,33 +344,33 @@ | |
| 344 | Though there is no `fossil whatchanged` command, the same sort of |
| 345 | information is available. For example, to pull the current changes from |
| 346 | the remote repository and then inspect them before updating the local |
| 347 | working directory, you might say this in Git: |
| 348 | |
| 349 | git fetch |
| 350 | git whatchanged ..@{u} |
| 351 | |
| 352 | …which you can approximate in Fossil as: |
| 353 | |
| 354 | fossil pull |
| 355 | fossil up -n |
| 356 | fossil diff --from tip |
| 357 | |
| 358 | To invert the `diff` to show a more natural patch, the command needs to |
| 359 | be a bit more complicated, since you can’t currently give `--to` |
| 360 | without `--from`. |
| 361 | |
| 362 | fossil diff --from current --to tip |
| 363 | |
| 364 | Rather than use the “dry run” form of [the `update` command][up], you can |
| 365 | say: |
| 366 | |
| 367 | fossil timeline after current |
| 368 | |
| 369 | …or if you want to restrict the output to the current branch: |
| 370 | |
| 371 | fossil timeline descendants current |
| 372 | |
| 373 | |
| 374 | #### <a id="ckin-names"></a> Symbolic Check-In Names |
| 375 | |
| 376 | Note the use of [human-readable symbolic version names][scin] in Fossil |
| @@ -377,42 +377,42 @@ | |
| 377 | rather than [Git’s cryptic notations][gcn]. |
| 378 | |
| 379 | For a more dramatic example of this, let us ask Git, “What changed since the |
| 380 | beginning of last month?” being October 2020 as I write this: |
| 381 | |
| 382 | git log master@{2020-10-01}..HEAD |
| 383 | |
| 384 | That’s rather obscure! Fossil answers the same question with a simpler |
| 385 | command: |
| 386 | |
| 387 | fossil timeline after 2020-10-01 |
| 388 | |
| 389 | You may need to add `-n 0` to bypass the default output limit of |
| 390 | `fossil timeline`, 20 entries. Without that, this command reads |
| 391 | almost like English. |
| 392 | |
| 393 | Some Git users like to write commands like the above so: |
| 394 | |
| 395 | git log @{2020-10-01}..@ |
| 396 | |
| 397 | Is that better? “@” now means two different things: an at-time reference |
| 398 | and a shortcut for `HEAD`! |
| 399 | |
| 400 | If you are one of those that like short commands, Fossil’s method is |
| 401 | less cryptic: it lets you shorten words in most cases up to the point |
| 402 | that they become ambiguous. For example, you may abbreviate the last |
| 403 | `fossil` command in the prior section: |
| 404 | |
| 405 | fossil tim d c |
| 406 | |
| 407 | …beyond which the `timeline` command becomes ambiguous with `ticket`. |
| 408 | |
| 409 | Some Fossil users employ shell aliases, symlinks, or scripts to shorten |
| 410 | the command still further: |
| 411 | |
| 412 | alias f=fossil |
| 413 | f tim d c |
| 414 | |
| 415 | Granted, that’s rather obscure, but you you can also choose something |
| 416 | intermediate like “`f time desc curr`”, which is reasonably clear. |
| 417 | |
| 418 | [35pct]: https://www.sqlite.org/fasterthanfs.html |
| @@ -468,11 +468,11 @@ | |
| 468 | automatically. There is no need for the "-a" option as with Git. |
| 469 | |
| 470 | If you only want to commit _some_ of the changes, list the names |
| 471 | of the files or directories you want to commit as arguments, like this: |
| 472 | |
| 473 | fossil commit src/feature.c doc/feature.md examples/feature |
| 474 | |
| 475 | Note that the last element is a directory name, meaning “any changed |
| 476 | file under the `examples/feature` directory.” |
| 477 | |
| 478 | Although there are currently no |
| @@ -482,12 +482,12 @@ | |
| 482 | running it through [Patchouli]. |
| 483 | |
| 484 | Rather than use `fossil diff -i` to produce such a patch, a safer and |
| 485 | more idiomatic method would be: |
| 486 | |
| 487 | fossil stash save -m 'my big ball-o-hackage' |
| 488 | fossil stash diff > my-changes.patch |
| 489 | |
| 490 | That stores your changes in the stash, then lets you operate on a copy |
| 491 | of that patch. Each time you re-run the second command, it will take the |
| 492 | current state of the working directory into account to produce a |
| 493 | potentially different patch, likely smaller because it leaves out patch |
| @@ -526,30 +526,30 @@ | |
| 526 | ## Create Branches at Point of Need, Rather Than Ahead of Need |
| 527 | |
| 528 | Fossil prefers that you create new branches as part of the first commit |
| 529 | on that branch: |
| 530 | |
| 531 | fossil commit --branch my-branch |
| 532 | |
| 533 | If that commit is successful, your local check-out directory is then |
| 534 | switched to the tip of that branch, so subsequent commits don’t need the |
| 535 | “`--branch`” option. You simply say `fossil commit` again to continue |
| 536 | adding commits to the tip of that branch. |
| 537 | |
| 538 | To switch back to the parent branch, say something like: |
| 539 | |
| 540 | fossil update trunk |
| 541 | |
| 542 | (This is approximately equivalent to `git checkout master`.) |
| 543 | |
| 544 | Fossil does also support the Git style, creating the branch ahead of |
| 545 | need: |
| 546 | |
| 547 | fossil branch new my-branch |
| 548 | fossil up my-branch |
| 549 | ...work on first commit... |
| 550 | fossil commit |
| 551 | |
| 552 | This is more verbose, giving the same overall effect though the initial |
| 553 | actions are inverted: create a new branch for the first commit, switch |
| 554 | the check-out directory to that branch, and make that first commit. As |
| 555 | above, subsequent commits are descendants of that initial branch commit. |
| @@ -558,11 +558,11 @@ | |
| 558 | |
| 559 | Fossil also allows you to move a check-in to a different branch |
| 560 | *after* you commit it, using the "`fossil amend`" command. |
| 561 | For example: |
| 562 | |
| 563 | fossil amend current --branch my-branch |
| 564 | |
| 565 | This works by inserting a tag into the repository that causes the web UI |
| 566 | to relabel commits from that point forward with the new name. Like Git, |
| 567 | Fossil’s fundamental data structure is the interlinked DAG of commit |
| 568 | hashes; branch names are supplemental data for making it easier for the |
| @@ -591,15 +591,15 @@ | |
| 591 | make them under this eventually-consistent design philosophy. |
| 592 | |
| 593 | Branch *names* sync automatically in Fossil, not just the |
| 594 | content of those branches. That means this common Git command: |
| 595 | |
| 596 | git push origin master |
| 597 | |
| 598 | …is simply this in Fossil: |
| 599 | |
| 600 | fossil push |
| 601 | |
| 602 | Fossil doesn’t need to be told what to push or where to push it: it just |
| 603 | keeps using the same remote server URL you gave it last |
| 604 | until you [tell it to do something different][rem]. It pushes all |
| 605 | branches, not just one named local branch. |
| @@ -613,11 +613,11 @@ | |
| 613 | |
| 614 | Fossil’s [autosync][wflow] feature, normally enabled, has no |
| 615 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 616 | it off: |
| 617 | |
| 618 | fossil set autosync 0 |
| 619 | |
| 620 | Let’s say that you have a typical server-and-workstations model with two |
| 621 | working clones on different machines, that you have disabled autosync, |
| 622 | and that this common sequence then occurs: |
| 623 | |
| @@ -692,16 +692,16 @@ | |
| 692 | by a colon. The simplified example above is also liable to become |
| 693 | confused by whitespace in file names.) |
| 694 | |
| 695 | |
| 696 | ``` |
| 697 | $ repo=$(fossil status | grep ^repo | cut -f2 -d:) |
| 698 | $ url=$(fossil remote) |
| 699 | $ fossil close # Stop here and think if it warns you! |
| 700 | $ mv $repo ${repo}.old |
| 701 | $ fossil clone $url $repo |
| 702 | $ fossil open --force $repo |
| 703 | ``` |
| 704 | |
| 705 | What, then, should you as a Git transplant do instead when you find |
| 706 | yourself reaching for “`git reset`”? |
| 707 | |
| @@ -717,13 +717,13 @@ | |
| 717 | sort of thing is unnecessary. |
| 718 | |
| 719 | Instead, Bob can say something like this: |
| 720 | |
| 721 | ``` |
| 722 | fossil amend --branch MISTAKE --hide --close -m "mea culpa" tip |
| 723 | fossil up trunk |
| 724 | fossil push |
| 725 | ``` |
| 726 | |
| 727 | Unlike in Git, the “`amend`” command doesn’t modify prior committed |
| 728 | artifacts. Bob’s first command doesn’t delete anything, merely tells |
| 729 | Fossil to hide his mistake from timeline views by inserting a few new |
| @@ -750,14 +750,14 @@ | |
| 750 | marked the branch as closed will prevent that from going thru, cluing |
| 751 | Alice into what she needs to do to remedy the situation, but that merely |
| 752 | shows why it’s a better workflow if Alice makes the amendment herself: |
| 753 | |
| 754 | ``` |
| 755 | fossil amend --branch MISTAKE --hide --close \ |
| 756 | -m "shunt Bob’s erroneous commit off" tip |
| 757 | fossil up trunk |
| 758 | fossil push |
| 759 | ``` |
| 760 | |
| 761 | Then she can fire off an email listing Bob’s assorted failings and go |
| 762 | about her work. This asynchronous workflow solves the problem without |
| 763 | requiring explicit coordination with Bob. When he gets his email, he can |
| @@ -834,18 +834,18 @@ | |
| 834 | Nevertheless, there are multiple ways to get colorized diff output from |
| 835 | Fossil: |
| 836 | |
| 837 | * The most direct method is to delegate diff behavior back to Git: |
| 838 | |
| 839 | fossil set --global diff-command 'git diff --no-index' |
| 840 | |
| 841 | The flag permits it to diff files that aren’t inside a Git repository. |
| 842 | |
| 843 | * Another method is to install [`colordiff`][cdiff] — included in |
| 844 | [many package systems][cdpkg] — then say: |
| 845 | |
| 846 | fossil set --global diff-command 'colordiff -wu' |
| 847 | |
| 848 | Because this is unconditional, unlike `git diff --color=auto`, you |
| 849 | will then have to remember to add the `-i` option to `fossil diff` |
| 850 | commands when you want color disabled, such as when producing |
| 851 | `patch(1)` files or piping diff output to another command that |
| @@ -876,15 +876,15 @@ | |
| 876 | functionality is present in Fossil under other commands: |
| 877 | |
| 878 | |
| 879 | #### <a id="patch"></a> Show a Patch for a Commit |
| 880 | |
| 881 | git show -p COMMIT_ID |
| 882 | |
| 883 | …gives much the same output as |
| 884 | |
| 885 | fossil diff --checkin COMMIT_ID |
| 886 | |
| 887 | …only without the patch email header. Git comes out of the [LKML] world, |
| 888 | where emailing a patch is a normal thing to do. Fossil is [designed for |
| 889 | cohesive teams][devorg] where drive-by patches are rarer. |
| 890 | |
| @@ -893,32 +893,32 @@ | |
| 893 | “`VERSION`” or “`NAME`” where this is allowed, since the version string |
| 894 | or name might not refer to a commit ID, but instead to a forum post, a |
| 895 | wiki document, etc. For instance, the following command answers the question “What did |
| 896 | I just commit?” |
| 897 | |
| 898 | fossil diff --checkin tip |
| 899 | |
| 900 | …or equivalently using a different symbolic commit name: |
| 901 | |
| 902 | fossil diff --from prev |
| 903 | |
| 904 | [devorg]: ./fossil-v-git.wiki#devorg |
| 905 | [LKML]: https://lkml.org/ |
| 906 | |
| 907 | |
| 908 | #### <a id="cmsg"></a> Show a Specific Commit Message |
| 909 | |
| 910 | git show -s COMMIT_ID |
| 911 | |
| 912 | |
| 913 | …is |
| 914 | |
| 915 | fossil time -n 1 COMMIT_ID |
| 916 | |
| 917 | …or with a shorter, more obvious command, though with more verbose output: |
| 918 | |
| 919 | fossil info COMMIT_ID |
| 920 | |
| 921 | The `fossil info` command isn’t otherwise a good equivalent to |
| 922 | `git show`; it just overlaps its functionality in some areas. Much of |
| 923 | what’s missing is present in the corresponding [`/info` web |
| 924 | view][infow], though. |
| @@ -927,17 +927,17 @@ | |
| 927 | #### <a id="dstat"></a> Diff Statistics |
| 928 | |
| 929 | Fossil’s closest internal equivalent to commands like |
| 930 | `git show --stat` is: |
| 931 | |
| 932 | fossil diff -i --from 2020-04-01 --numstat |
| 933 | |
| 934 | The `--numstat` output is a bit cryptic, so we recommend delegating |
| 935 | this task to [the widely-available `diffstat` tool][dst], which gives |
| 936 | a histogram in its default output mode rather than bare integers: |
| 937 | |
| 938 | fossil diff -i -v --from 2020-04-01 | diffstat |
| 939 | |
| 940 | We gave the `-i` flag in both cases to force Fossil to use its internal |
| 941 | diff implementation, bypassing [your local `diff-command` setting][dcset]. |
| 942 | The `--numstat` option has no effect when you have an external diff |
| 943 | command set, and some diff command alternatives like |
| @@ -999,19 +999,19 @@ | |
| 999 | default: they do not actually rename or delete the files in your |
| 1000 | check-out. |
| 1001 | |
| 1002 | If you don’t like that default, you can change it globally: |
| 1003 | |
| 1004 | fossil setting --global mv-rm-files 1 |
| 1005 | |
| 1006 | Now these commands behave like in Git in any Fossil repository where |
| 1007 | this setting hasn’t been overridden locally. |
| 1008 | |
| 1009 | If you want to keep Fossil’s soft `mv/rm` behavior most of the time, you |
| 1010 | can cast it away on a per-command basis: |
| 1011 | |
| 1012 | fossil mv --hard old-name new-name |
| 1013 | |
| 1014 | [mv]: /help?cmd=mv |
| 1015 | [rm]: /help?cmd=rm |
| 1016 | |
| 1017 | |
| @@ -1032,11 +1032,11 @@ | |
| 1032 | |
| 1033 | My search engine’s first result for “git checkout by date” is [this |
| 1034 | highly-upvoted accepted Stack Overflow answer][gcod]. The first command |
| 1035 | it gives is based on Git’s [`rev-parse` feature][grp]: |
| 1036 | |
| 1037 | git checkout master@{2020-03-17} |
| 1038 | |
| 1039 | There are a number of weaknesses in this command. From least to most |
| 1040 | critical: |
| 1041 | |
| 1042 | 1. It’s a bit cryptic. Leave off the refname or punctuation, and it |
| @@ -1072,11 +1072,11 @@ | |
| 1072 | best case. |
| 1073 | |
| 1074 | That same Stack Overflow answer therefore goes on to recommend an |
| 1075 | entirely different command: |
| 1076 | |
| 1077 | git checkout $(git rev-list -n 1 --first-parent --before="2020-03-17" master) |
| 1078 | |
| 1079 | We believe you get such answers to Git help requests in part |
| 1080 | because of its lack of an always-up-to-date [index into its log](#log) and in |
| 1081 | part because of its “small tools loosely joined” design philosophy. This |
| 1082 | sort of command is therefore composed piece by piece: |
| @@ -1084,36 +1084,36 @@ | |
| 1084 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1085 | |
| 1086 | “Oh, I know, I’ll search the rev-list, which outputs commit IDs by |
| 1087 | parsing the log backwards from `HEAD`! Easy!” |
| 1088 | |
| 1089 | git rev-list --before=2020-03-17 |
| 1090 | |
| 1091 | “Blast! Forgot the commit ID!” |
| 1092 | |
| 1093 | git rev-list --before=2020-03-17 master |
| 1094 | |
| 1095 | “Double blast! It just spammed my terminal with revision IDs! I need to |
| 1096 | limit it to the single closest match: |
| 1097 | |
| 1098 | git rev-list -n 1 --before=2020-03-17 master |
| 1099 | |
| 1100 | “Okay, it gives me a single revision ID now, but is it what I’m after? |
| 1101 | Let’s take a look…” |
| 1102 | |
| 1103 | git show $(git rev-list -n 1 --before=2020-03-17 master) |
| 1104 | |
| 1105 | “Oops, that’s giving me a merge commit, not what I want. |
| 1106 | Off to search the web… Okay, it says I need to give either the |
| 1107 | `--first-parent` or `--no-merges` flag to show only regular commits, |
| 1108 | not merge-commits. Let’s try the first one:” |
| 1109 | |
| 1110 | git show $(git rev-list -n 1 --first-parent --before=2020-03-17 master) |
| 1111 | |
| 1112 | “Better. Let’s check it out:” |
| 1113 | |
| 1114 | git checkout $(git rev-list -n 1 --first-parent --before=2020-03-17 master) |
| 1115 | |
| 1116 | “Success, I guess?” |
| 1117 | |
| 1118 | <p style="text-align:center">◆ ◆ ◆</p> |
| 1119 | |
| @@ -1132,11 +1132,11 @@ | |
| 1132 | 17th of March, 2020. |
| 1133 | |
| 1134 | You may be asking with an exasperated huff, “What is your *point*, man?” |
| 1135 | The point is that the equivalent in Fossil is simply: |
| 1136 | |
| 1137 | fossil up 2020-03-17 |
| 1138 | |
| 1139 | …which will *always* give the commit closest to midnight UTC on the 17th |
| 1140 | of March, 2020, no matter whether you do it on a fresh clone or a stale |
| 1141 | one. The answer won’t shift about from one clone to the next or from |
| 1142 | one local time of day to the next. We owe this reliability and stability |
| @@ -1181,13 +1181,13 @@ | |
| 1181 | #### Git Method |
| 1182 | |
| 1183 | We first need to clone the work repo down to our laptop, so we can work on it |
| 1184 | at home: |
| 1185 | |
| 1186 | git clone https://dev-server.example.com/repo |
| 1187 | cd repo |
| 1188 | git remote rename origin work |
| 1189 | |
| 1190 | The last command is optional, strictly speaking. We could continue to |
| 1191 | use Git’s default name for the work repo’s origin — sensibly enough |
| 1192 | called “`origin`” — but it makes later commands harder to understand, so |
| 1193 | we rename it here. This will also make the parallel with Fossil easier |
| @@ -1194,12 +1194,12 @@ | |
| 1194 | to draw. |
| 1195 | |
| 1196 | The first time we go home after this, we have to reverse-clone the work |
| 1197 | repo up to the NAS: |
| 1198 | |
| 1199 | ssh my-nas.local 'git init --bare /SHARES/dayjob/repo.git' |
| 1200 | git push --all ssh://my-nas.local//SHARES/dayjob/repo.git |
| 1201 | |
| 1202 | Realize that this is carefully optimized down to these two long |
| 1203 | commands. In practice, we’d expect a user typing these commands by hand from memory |
| 1204 | to need to give four or more commands here instead. |
| 1205 | Packing the “`git init`” call into the “`ssh`” call is something more |
| @@ -1213,31 +1213,31 @@ | |
| 1213 | |
| 1214 | Having navigated that little minefield, |
| 1215 | we can tell Git that there is a second origin, a “home” repo in |
| 1216 | addition to the named “work” repo we set up earlier: |
| 1217 | |
| 1218 | git remote add home ssh://my-nas.local//SHARES/dayjob/repo.git |
| 1219 | git config master.remote home |
| 1220 | |
| 1221 | We don’t have to push or pull because the remote repo is a complete |
| 1222 | clone of the repo on the laptop at this point, so we can just get to |
| 1223 | work now, committing along the way to get our work safely off-machine |
| 1224 | and onto our home NAS, like so: |
| 1225 | |
| 1226 | git add |
| 1227 | git commit |
| 1228 | git push |
| 1229 | |
| 1230 | We didn’t need to give a remote name on the push because we told it the |
| 1231 | new upstream is the home NAS earlier. |
| 1232 | |
| 1233 | Now Friday comes along, and one of your office-mates needs a feature |
| 1234 | you’re working on. You agree to come into the office later that |
| 1235 | afternoon to sync up via the dev server: |
| 1236 | |
| 1237 | git push work master # send your changes from home up |
| 1238 | git pull work master # get your coworkers’ changes |
| 1239 | |
| 1240 | Alternately, we could add “`--set-upstream/-u work`” to the first |
| 1241 | command if we were coming into work long enough to do several Git-based things, not just pop in and sync. |
| 1242 | That would allow the second to be just “`git pull`”, but the cost is |
| 1243 | that when returning home, you’d have to manually reset the upstream |
| @@ -1254,13 +1254,13 @@ | |
| 1254 | Now we’re going to do the same thing using Fossil, with |
| 1255 | the commands arranged in blocks corresponding to those above for comparison. |
| 1256 | |
| 1257 | We start the same way, cloning the work repo down to the laptop: |
| 1258 | |
| 1259 | fossil clone https://dev-server.example.com/repo |
| 1260 | cd repo |
| 1261 | fossil remote add work https://dev-server.example.com/repo |
| 1262 | |
| 1263 | We’ve chosen the new “`fossil clone URI`” syntax added in Fossil 2.14 rather than separate |
| 1264 | `clone` and `open` commands to make the parallel with Git clearer. [See |
| 1265 | above](#mwd) for more on that topic. |
| 1266 | |
| @@ -1278,11 +1278,11 @@ | |
| 1278 | below. |
| 1279 | |
| 1280 | On first beginning to work from home, we reverse-clone the Fossil repo |
| 1281 | up to the NAS: |
| 1282 | |
| 1283 | rsync repo.fossil my-nas.local:/SHARES/dayjob/ |
| 1284 | |
| 1285 | Now we’re beginning to see the advantage of Fossil’s simpler model, |
| 1286 | relative to the tricky “`git init && git push`” sequence above. |
| 1287 | Fossil’s alternative is almost impossible to get |
| 1288 | wrong: copy this to that. *Done.* |
| @@ -1297,12 +1297,12 @@ | |
| 1297 | inherent in using `rsync` to clone a Git repo][grsync]. |
| 1298 | |
| 1299 | Now we set up the second remote, which is again simpler in the Fossil |
| 1300 | case: |
| 1301 | |
| 1302 | fossil remote add home ssh://my-nas.local//SHARES/dayjob/repo.fossil |
| 1303 | fossil remote home |
| 1304 | |
| 1305 | The first command is nearly identical to the Git version, but the second |
| 1306 | is considerably simpler. And to be fair, you won’t find the |
| 1307 | “`git config`” command above in all Git tutorials. The more common |
| 1308 | alternative we found with web searches is even longer: |
| @@ -1309,21 +1309,21 @@ | |
| 1309 | “`git push --set-upstream home master`”. |
| 1310 | |
| 1311 | Where Fossil really wins is in the next step, making the initial commit |
| 1312 | from home: |
| 1313 | |
| 1314 | fossil ci |
| 1315 | |
| 1316 | It’s one short command for Fossil instead of three for Git — or two if |
| 1317 | you abbreviate it as “`git commit -a && git push`” — because of Fossil’s |
| 1318 | [autosync] feature and deliberate omission of a |
| 1319 | [staging feature](#staging). |
| 1320 | |
| 1321 | The “Friday afternoon sync-up” case is simpler, too: |
| 1322 | |
| 1323 | fossil remote work |
| 1324 | fossil sync |
| 1325 | |
| 1326 | Back at home, it’s simpler still: we may be able to do away with the second command, |
| 1327 | saying just “`fossil remote home`” because the sync will happen as part |
| 1328 | of the next commit, thanks once again to Fossil’s autosync feature. If |
| 1329 | the working branch now has commits from other developers after syncing |
| 1330 |