Fossil SCM
Added the "Update vs Pull" section to the gitusers doc.
Commit
eadc427d3edd2e7f501eac663c2d78d8ef4109fae3228e128e466e9f92b5a184
Parent
a5ea7891599eb3b…
2 files changed
+36
-1
+1
-1
+36
-1
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -78,15 +78,50 @@ | ||
| 78 | 78 | |
| 79 | 79 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 80 | 80 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 81 | 81 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 82 | 82 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| 83 | -than `fossil checkout`. | |
| 83 | +than `fossil checkout`. That said, one of those differences does match | |
| 84 | +up with Git users’ expectations: `fossil checkout` doesn’t pull changes | |
| 85 | +from the remote repository into the local clone as `fossil update` does. | |
| 86 | +We think this is less broadly useful, but that’s the subject of the next | |
| 87 | +section. | |
| 84 | 88 | |
| 85 | 89 | [ckwf]: ./ckout-workflows.md |
| 86 | 90 | [co]: /help?cmd=checkout |
| 87 | 91 | |
| 92 | + | |
| 93 | +#### <a id="pullup"></a> Update vs Pull | |
| 94 | + | |
| 95 | +The closest equivalent to [`git pull`][gpull] is [`fossil up`][up], | |
| 96 | +since Fossil tends to follow the CVS command design: `cvs up` pulls | |
| 97 | +changes from the central CVS repository and merges them into the local | |
| 98 | +working directory, so that’s what `fossil up` does, too. | |
| 99 | + | |
| 100 | +There is a `fossil pull` command, but it is simply the reverse of | |
| 101 | +`fossil push`, so that `fossil sync` [is functionally equivalent | |
| 102 | +to](./sync.wiki#sync): | |
| 103 | + | |
| 104 | + fossil push ; fossil pull | |
| 105 | + | |
| 106 | +There is no “and update the local working directory” step in Fossil’s | |
| 107 | +push, pull, or sync commands, as with `git pull`. | |
| 108 | + | |
| 109 | +This makes `fossil up` dual-use: | |
| 110 | + | |
| 111 | +* Without the optional `VERSION` argument, it updates the working | |
| 112 | + checkout to the tip of the current branch. | |
| 113 | + | |
| 114 | +* With that argument, it updates to the named version. If that’s the | |
| 115 | + name of a branch, it updates to the tip of that branch rather than | |
| 116 | + the current one. | |
| 117 | + | |
| 118 | +We think this is a more sensible command design than `git checkout` vs | |
| 119 | +`git pull`. | |
| 120 | + | |
| 121 | +[gpull]: https://git-scm.com/docs/git-pull | |
| 122 | + | |
| 88 | 123 | |
| 89 | 124 | #### <a id="rname"></a> Naming Repositories |
| 90 | 125 | |
| 91 | 126 | The Fossil repository database file can be named anything |
| 92 | 127 | you want, with a single exception: if you’re going to use the |
| 93 | 128 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -78,15 +78,50 @@ | |
| 78 | |
| 79 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 80 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 81 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 82 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| 83 | than `fossil checkout`. |
| 84 | |
| 85 | [ckwf]: ./ckout-workflows.md |
| 86 | [co]: /help?cmd=checkout |
| 87 | |
| 88 | |
| 89 | #### <a id="rname"></a> Naming Repositories |
| 90 | |
| 91 | The Fossil repository database file can be named anything |
| 92 | you want, with a single exception: if you’re going to use the |
| 93 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -78,15 +78,50 @@ | |
| 78 | |
| 79 | …in Fossil. There is a [`fossil checkout`][co] command, but it has |
| 80 | [several differences](./co-vs-up.md) that make it less broadly useful |
| 81 | than [`fossil update`][up] in everyday operation, so we recommend that |
| 82 | Git users moving to Fossil develop a habit of typing `fossil up` rather |
| 83 | than `fossil checkout`. That said, one of those differences does match |
| 84 | up with Git users’ expectations: `fossil checkout` doesn’t pull changes |
| 85 | from the remote repository into the local clone as `fossil update` does. |
| 86 | We think this is less broadly useful, but that’s the subject of the next |
| 87 | section. |
| 88 | |
| 89 | [ckwf]: ./ckout-workflows.md |
| 90 | [co]: /help?cmd=checkout |
| 91 | |
| 92 | |
| 93 | #### <a id="pullup"></a> Update vs Pull |
| 94 | |
| 95 | The closest equivalent to [`git pull`][gpull] is [`fossil up`][up], |
| 96 | since Fossil tends to follow the CVS command design: `cvs up` pulls |
| 97 | changes from the central CVS repository and merges them into the local |
| 98 | working directory, so that’s what `fossil up` does, too. |
| 99 | |
| 100 | There is a `fossil pull` command, but it is simply the reverse of |
| 101 | `fossil push`, so that `fossil sync` [is functionally equivalent |
| 102 | to](./sync.wiki#sync): |
| 103 | |
| 104 | fossil push ; fossil pull |
| 105 | |
| 106 | There is no “and update the local working directory” step in Fossil’s |
| 107 | push, pull, or sync commands, as with `git pull`. |
| 108 | |
| 109 | This makes `fossil up` dual-use: |
| 110 | |
| 111 | * Without the optional `VERSION` argument, it updates the working |
| 112 | checkout to the tip of the current branch. |
| 113 | |
| 114 | * With that argument, it updates to the named version. If that’s the |
| 115 | name of a branch, it updates to the tip of that branch rather than |
| 116 | the current one. |
| 117 | |
| 118 | We think this is a more sensible command design than `git checkout` vs |
| 119 | `git pull`. |
| 120 | |
| 121 | [gpull]: https://git-scm.com/docs/git-pull |
| 122 | |
| 123 | |
| 124 | #### <a id="rname"></a> Naming Repositories |
| 125 | |
| 126 | The Fossil repository database file can be named anything |
| 127 | you want, with a single exception: if you’re going to use the |
| 128 |
+1
-1
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -913,11 +913,11 @@ | ||
| 913 | 913 | server knows all artifacts that exist on the client. Also, as with |
| 914 | 914 | pull, the client attempts to keep the size of the request from |
| 915 | 915 | growing too large by suppressing file cards once the |
| 916 | 916 | size of the request reaches 1MB.</p> |
| 917 | 917 | |
| 918 | -<h3>5.3 Sync</h3> | |
| 918 | +<h3 id="sync">5.3 Sync</h3> | |
| 919 | 919 | |
| 920 | 920 | <p>A sync is just a pull and a push that happen at the same time. |
| 921 | 921 | The first three steps of a pull are combined with the first five steps |
| 922 | 922 | of a push. Steps (4) through (7) of a pull are combined with steps |
| 923 | 923 | (5) through (8) of a push. And steps (8) through (10) of a pull |
| 924 | 924 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -913,11 +913,11 @@ | |
| 913 | server knows all artifacts that exist on the client. Also, as with |
| 914 | pull, the client attempts to keep the size of the request from |
| 915 | growing too large by suppressing file cards once the |
| 916 | size of the request reaches 1MB.</p> |
| 917 | |
| 918 | <h3>5.3 Sync</h3> |
| 919 | |
| 920 | <p>A sync is just a pull and a push that happen at the same time. |
| 921 | The first three steps of a pull are combined with the first five steps |
| 922 | of a push. Steps (4) through (7) of a pull are combined with steps |
| 923 | (5) through (8) of a push. And steps (8) through (10) of a pull |
| 924 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -913,11 +913,11 @@ | |
| 913 | server knows all artifacts that exist on the client. Also, as with |
| 914 | pull, the client attempts to keep the size of the request from |
| 915 | growing too large by suppressing file cards once the |
| 916 | size of the request reaches 1MB.</p> |
| 917 | |
| 918 | <h3 id="sync">5.3 Sync</h3> |
| 919 | |
| 920 | <p>A sync is just a pull and a push that happen at the same time. |
| 921 | The first three steps of a pull are combined with the first five steps |
| 922 | of a push. Steps (4) through (7) of a pull are combined with steps |
| 923 | (5) through (8) of a push. And steps (8) through (10) of a pull |
| 924 |