Fossil SCM
Rewrote "No rebasing" section in fossil-v-git for clarity
Commit
970e9173d472ecc5578b44f416593715bf8008a976f27c4a4c8be0657c213450
Parent
d178c782d3b2ed7…
1 file changed
+4
-4
+4
-4
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -202,14 +202,14 @@ | ||
| 202 | 202 | than firing off a PR.² This difference comes directly from the |
| 203 | 203 | initial designed purpose for each tool: the SQLite project doesn't |
| 204 | 204 | accept outside contributions from previously-unknown developers, but |
| 205 | 205 | the Linux kernel does.</p></li> |
| 206 | 206 | |
| 207 | - <li><p><b>No rebasing:</b> When a remote clone syncs changes up to | |
| 208 | - its parent repository, the changes are sent exactly as they were | |
| 209 | - committed to the local repository. [#history|There is no rebasing | |
| 210 | - mechanism, on purpose.]</p></li> | |
| 207 | + <li><p><b>No rebasing:</b> When your local repo clone syncs changes | |
| 208 | + up to its parent, those changes are sent exactly as they were | |
| 209 | + committed locally. [#history|There is no rebasing mechanism in | |
| 210 | + Fossil, on purpose.]</p></li> | |
| 211 | 211 | |
| 212 | 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | 213 | Fossil-based projects; the default is to rely on |
| 214 | 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | 215 | normally syncs immediately to its parent repository, so that |
| 216 | 216 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -202,14 +202,14 @@ | |
| 202 | than firing off a PR.² This difference comes directly from the |
| 203 | initial designed purpose for each tool: the SQLite project doesn't |
| 204 | accept outside contributions from previously-unknown developers, but |
| 205 | the Linux kernel does.</p></li> |
| 206 | |
| 207 | <li><p><b>No rebasing:</b> When a remote clone syncs changes up to |
| 208 | its parent repository, the changes are sent exactly as they were |
| 209 | committed to the local repository. [#history|There is no rebasing |
| 210 | mechanism, on purpose.]</p></li> |
| 211 | |
| 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | Fossil-based projects; the default is to rely on |
| 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | normally syncs immediately to its parent repository, so that |
| 216 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -202,14 +202,14 @@ | |
| 202 | than firing off a PR.² This difference comes directly from the |
| 203 | initial designed purpose for each tool: the SQLite project doesn't |
| 204 | accept outside contributions from previously-unknown developers, but |
| 205 | the Linux kernel does.</p></li> |
| 206 | |
| 207 | <li><p><b>No rebasing:</b> When your local repo clone syncs changes |
| 208 | up to its parent, those changes are sent exactly as they were |
| 209 | committed locally. [#history|There is no rebasing mechanism in |
| 210 | Fossil, on purpose.]</p></li> |
| 211 | |
| 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | Fossil-based projects; the default is to rely on |
| 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | normally syncs immediately to its parent repository, so that |
| 216 |