Fossil SCM
Better example of Git focusing on single-branch syncing, allowing removal of the "dispute" commentary.
Commit
03f2393dae86661dea368dffc2c30bf48f2542337d2b31a6fa8ac52ce633ad26
Parent
e4beb0be58a66df…
1 file changed
+4
-6
+4
-6
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -583,13 +583,14 @@ | ||
| 583 | 583 | |
| 584 | 584 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 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 | -For example, the default behavior in Git is to only synchronize | |
| 589 | -a single branch, whereas with Fossil the only sync option is to | |
| 590 | -sync the entire DAG. Git commands, | |
| 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, | |
| 591 | 592 | GitHub, and GitLab tend to show only a single branch at |
| 592 | 593 | a time, whereas Fossil usually shows all parallel branches at |
| 593 | 594 | once. Git has commands like "rebase" that help keep all relevant |
| 594 | 595 | changes on a single branch, whereas Fossil encourages a style of |
| 595 | 596 | many concurrent branches constantly springing into existence, |
| @@ -605,13 +606,10 @@ | ||
| 605 | 606 | and its handful of active committers. Seeing all |
| 606 | 607 | changes on all branches all at once helps keep the whole team |
| 607 | 608 | up-to-date with what everybody else is doing, resulting in a more |
| 608 | 609 | tightly focused and cohesive implementation. |
| 609 | 610 | |
| 610 | -Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed] | |
| 611 | -by [https://github.com/olorin37|Jakub A. G.]. | |
| 612 | - | |
| 613 | 611 | |
| 614 | 612 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 615 | 613 | |
| 616 | 614 | Because Git commingles the repository data with the initial checkout of |
| 617 | 615 | that repository, the default mode of operation in Git is to stick to that |
| 618 | 616 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -583,13 +583,14 @@ | |
| 583 | |
| 584 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 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 | For example, the default behavior in Git is to only synchronize |
| 589 | a single branch, whereas with Fossil the only sync option is to |
| 590 | sync the entire DAG. Git commands, |
| 591 | GitHub, and GitLab tend to show only a single branch at |
| 592 | a time, whereas Fossil usually shows all parallel branches at |
| 593 | once. Git has commands like "rebase" that help keep all relevant |
| 594 | changes on a single branch, whereas Fossil encourages a style of |
| 595 | many concurrent branches constantly springing into existence, |
| @@ -605,13 +606,10 @@ | |
| 605 | and its handful of active committers. Seeing all |
| 606 | changes on all branches all at once helps keep the whole team |
| 607 | up-to-date with what everybody else is doing, resulting in a more |
| 608 | tightly focused and cohesive implementation. |
| 609 | |
| 610 | Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed] |
| 611 | by [https://github.com/olorin37|Jakub A. G.]. |
| 612 | |
| 613 | |
| 614 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 615 | |
| 616 | Because Git commingles the repository data with the initial checkout of |
| 617 | that repository, the default mode of operation in Git is to stick to that |
| 618 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -583,13 +583,14 @@ | |
| 583 | |
| 584 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 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 | many concurrent branches constantly springing into existence, |
| @@ -605,13 +606,10 @@ | |
| 606 | and its handful of active committers. Seeing all |
| 607 | changes on all branches all at once helps keep the whole team |
| 608 | up-to-date with what everybody else is doing, resulting in a more |
| 609 | tightly focused and cohesive implementation. |
| 610 | |
| 611 | |
| 612 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 613 | |
| 614 | Because Git commingles the repository data with the initial checkout of |
| 615 | that repository, the default mode of operation in Git is to stick to that |
| 616 |