Fossil SCM
Clarity tweaks to §2.5.3 of previous
Commit
4146f2d04ef8208e9eb5c833ad2b538fd00d10b546ce01433829db5cd7725298
Parent
03f2393dae86661…
1 file changed
+2
-2
+2
-2
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -585,11 +585,11 @@ | ||
| 585 | 585 | of changes, but Git tends to focus more on individual branches of |
| 586 | 586 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 587 | 587 | |
| 588 | 588 | While a common usage pattern in Git is to only synchronize |
| 589 | 589 | a single branch — <tt>git pull upstream feature/branch</tt> — instead |
| 590 | -of all refs Fossil does not give you a choice; it | |
| 590 | +of all refs, Fossil does not give you a choice; it | |
| 591 | 591 | syncs the entire DAG or nothing. Git commands, |
| 592 | 592 | GitHub, and GitLab tend to show only a single branch at |
| 593 | 593 | a time, whereas Fossil usually shows all parallel branches at |
| 594 | 594 | once. Git has commands like "rebase" that help keep all relevant |
| 595 | 595 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -596,11 +596,11 @@ | ||
| 596 | 596 | many concurrent branches constantly springing into existence, |
| 597 | 597 | undergoing active development in parallel for a few days or weeks, then |
| 598 | 598 | merging back into the main line and disappearing. |
| 599 | 599 | |
| 600 | 600 | This difference in emphasis arises from the different purposes of |
| 601 | -the two systems. Git focuses on individual branches, because that | |
| 601 | +the two systems. Git's focus on individual branches | |
| 602 | 602 | is exactly what you want for a highly-distributed bazaar-style project |
| 603 | 603 | such as Linux. Linus Torvalds does not want to see every check-in |
| 604 | 604 | by every contributor to Linux: such extreme visibility does not scale |
| 605 | 605 | well. Contrast Fossil, which was written for the cathedral-style SQLite project |
| 606 | 606 | and its handful of active committers. Seeing all |
| 607 | 607 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -585,11 +585,11 @@ | |
| 585 | of changes, but Git tends to focus more on individual branches of |
| 586 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 587 | |
| 588 | While a common usage pattern in Git is to only synchronize |
| 589 | a single branch — <tt>git pull upstream feature/branch</tt> — instead |
| 590 | of all refs Fossil does not give you a choice; it |
| 591 | syncs the entire DAG or nothing. Git commands, |
| 592 | GitHub, and GitLab tend to show only a single branch at |
| 593 | a time, whereas Fossil usually shows all parallel branches at |
| 594 | once. Git has commands like "rebase" that help keep all relevant |
| 595 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -596,11 +596,11 @@ | |
| 596 | many concurrent branches constantly springing into existence, |
| 597 | undergoing active development in parallel for a few days or weeks, then |
| 598 | merging back into the main line and disappearing. |
| 599 | |
| 600 | This difference in emphasis arises from the different purposes of |
| 601 | the two systems. Git focuses on individual branches, because that |
| 602 | is exactly what you want for a highly-distributed bazaar-style project |
| 603 | such as Linux. Linus Torvalds does not want to see every check-in |
| 604 | by every contributor to Linux: such extreme visibility does not scale |
| 605 | well. Contrast Fossil, which was written for the cathedral-style SQLite project |
| 606 | and its handful of active committers. Seeing all |
| 607 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -585,11 +585,11 @@ | |
| 585 | of changes, but Git tends to focus more on individual branches of |
| 586 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 587 | |
| 588 | While a common usage pattern in Git is to only synchronize |
| 589 | a single branch — <tt>git pull upstream feature/branch</tt> — instead |
| 590 | of all refs, Fossil does not give you a choice; it |
| 591 | syncs the entire DAG or nothing. Git commands, |
| 592 | GitHub, and GitLab tend to show only a single branch at |
| 593 | a time, whereas Fossil usually shows all parallel branches at |
| 594 | once. Git has commands like "rebase" that help keep all relevant |
| 595 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -596,11 +596,11 @@ | |
| 596 | many concurrent branches constantly springing into existence, |
| 597 | undergoing active development in parallel for a few days or weeks, then |
| 598 | merging back into the main line and disappearing. |
| 599 | |
| 600 | This difference in emphasis arises from the different purposes of |
| 601 | the two systems. Git's focus on individual branches |
| 602 | is exactly what you want for a highly-distributed bazaar-style project |
| 603 | such as Linux. Linus Torvalds does not want to see every check-in |
| 604 | by every contributor to Linux: such extreme visibility does not scale |
| 605 | well. Contrast Fossil, which was written for the cathedral-style SQLite project |
| 606 | and its handful of active committers. Seeing all |
| 607 |