Fossil SCM
In the fossil-v-git.wiki document, remove the section titled "Accepting Contributions" as it does not seem to move the argument forward (as far as I can see) but it has provoked unnecessary pushback from Git enthusiasts.
Commit
b3080a2286d701f5b18779f85d6179358aed8f77d5aae2d861019b8b2d7912e6
Parent
c34b644eda0a37a…
1 file changed
+1
-70
+1
-70
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -543,80 +543,11 @@ | ||
| 543 | 543 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 544 | 544 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 545 | 545 | not the best way to hang a picture on the living room wall. |
| 546 | 546 | |
| 547 | 547 | |
| 548 | -<h4 id="contrib">2.5.3 Accepting Contributions</h4> | |
| 549 | - | |
| 550 | -As of this writing, Git has received about 4.5 times as many commits as | |
| 551 | -Fossil resulting in about 2.5 times as many lines of source code. The line | |
| 552 | -count excludes tests and in-tree third-party dependencies. It does not | |
| 553 | -exclude the default GUI for each, since it's integral for Fossil, so we | |
| 554 | -count the size of <tt>gitk</tt> in this. | |
| 555 | - | |
| 556 | -It is obvious that Git is bigger in part because of its first-mover | |
| 557 | -advantage, which resulted in a larger user community, which results in | |
| 558 | -more contributions. But is that the <i>only</i> reason? We believe there | |
| 559 | -are other relevant differences that also play into this which fall out | |
| 560 | -of the "Linux vs. SQLite" framing: licensing, community structure, and | |
| 561 | -how we react to | |
| 562 | -[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by | |
| 563 | -contributions]. In brief, it's harder to get a new feature into Fossil | |
| 564 | -than into Git. | |
| 565 | - | |
| 566 | -A larger feature set is not necessarily a good thing. Git's command line | |
| 567 | -interface is famously arcane. Masters of the arcane are able to do | |
| 568 | -wizardly things, but only by studying their art deeply for years. This | |
| 569 | -strikes us as a good thing only in cases where use of the tool itself is | |
| 570 | -the primary point of that user's work. | |
| 571 | - | |
| 572 | -Almost no one uses a DVCS for its own sake; very few people get paid | |
| 573 | -specifically in order to drive a DVCS. We use DVCSes as a tool to | |
| 574 | -support some other effort, so we do not necessarily want the DVCS with | |
| 575 | -the most features. We want a DVCS with easily internalized behavior so | |
| 576 | -we can thoroughly master it despite spending only a small fraction of | |
| 577 | -our working time thinking about the DVCS. We want to pick the tool up, | |
| 578 | -use it quickly, and then set it aside in order to get back to our actual | |
| 579 | -job as quickly as possible. | |
| 580 | - | |
| 581 | -Professional software developers in particular are prone to focusing on | |
| 582 | -feature set sizes when choosing tools because this is sometimes a highly | |
| 583 | -important consideration. They spend all day, every day, in their | |
| 584 | -favorite text editors, and time they spend learning all of the arcana of | |
| 585 | -their favorite programming languages is well-spent. Skills with these | |
| 586 | -tools are direct productivity drivers, which in turn directly drives how | |
| 587 | -much money a developer can make. (Or how much idle time they can afford | |
| 588 | -to take, which amounts to the same thing.) But if you are a professional | |
| 589 | -software developer, we want you to ask yourself a question: "How do I | |
| 590 | -get paid more by mastering arcane features of my DVCS?" Unless you have | |
| 591 | -a good answer to that, you probably do not want to be choosing a DVCS | |
| 592 | -based on how many arcane features it has. | |
| 593 | - | |
| 594 | -The argument is similar for other types of users: if you are a hobbyist, | |
| 595 | -how much time do you want to spend mastering your DVCS instead of on | |
| 596 | -the hobby supported by use of that DVCS? | |
| 597 | - | |
| 598 | -There is some minimal set of features required to achieve the purposes | |
| 599 | -that drive our selection of a DVCS, but there is a level beyond which | |
| 600 | -more features only slow us down while we're learning the tool, since we | |
| 601 | -must plow through documentation on features we're not likely to ever | |
| 602 | -use. When the number of features grows to the point where people of | |
| 603 | -normal motivation cannot spend the time to master them all, the tool | |
| 604 | -becomes <i>less</i> productive to use. | |
| 605 | - | |
| 606 | -The core developers of the Fossil project achieve a balance between feature | |
| 607 | -set size and ease of use by | |
| 608 | -carefully choosing which users to give commit bits to, then in being | |
| 609 | -choosy about which of the contributed feature branches to merge down to | |
| 610 | -trunk. We say "no" to a lot of feature proposals. | |
| 611 | - | |
| 612 | -The end result is that Fossil more closely adheres to | |
| 613 | -[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the | |
| 614 | -principle of least astonishment] than Git does. | |
| 615 | - | |
| 616 | - | |
| 617 | -<h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4> | |
| 548 | +<h4 id="branches">2.5.3 Individual Branches vs. The Entire Change History</h4> | |
| 618 | 549 | |
| 619 | 550 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 620 | 551 | of changes, but Git tends to focus more on individual branches of |
| 621 | 552 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 622 | 553 | |
| 623 | 554 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -543,80 +543,11 @@ | |
| 543 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 544 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 545 | not the best way to hang a picture on the living room wall. |
| 546 | |
| 547 | |
| 548 | <h4 id="contrib">2.5.3 Accepting Contributions</h4> |
| 549 | |
| 550 | As of this writing, Git has received about 4.5 times as many commits as |
| 551 | Fossil resulting in about 2.5 times as many lines of source code. The line |
| 552 | count excludes tests and in-tree third-party dependencies. It does not |
| 553 | exclude the default GUI for each, since it's integral for Fossil, so we |
| 554 | count the size of <tt>gitk</tt> in this. |
| 555 | |
| 556 | It is obvious that Git is bigger in part because of its first-mover |
| 557 | advantage, which resulted in a larger user community, which results in |
| 558 | more contributions. But is that the <i>only</i> reason? We believe there |
| 559 | are other relevant differences that also play into this which fall out |
| 560 | of the "Linux vs. SQLite" framing: licensing, community structure, and |
| 561 | how we react to |
| 562 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 563 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 564 | than into Git. |
| 565 | |
| 566 | A larger feature set is not necessarily a good thing. Git's command line |
| 567 | interface is famously arcane. Masters of the arcane are able to do |
| 568 | wizardly things, but only by studying their art deeply for years. This |
| 569 | strikes us as a good thing only in cases where use of the tool itself is |
| 570 | the primary point of that user's work. |
| 571 | |
| 572 | Almost no one uses a DVCS for its own sake; very few people get paid |
| 573 | specifically in order to drive a DVCS. We use DVCSes as a tool to |
| 574 | support some other effort, so we do not necessarily want the DVCS with |
| 575 | the most features. We want a DVCS with easily internalized behavior so |
| 576 | we can thoroughly master it despite spending only a small fraction of |
| 577 | our working time thinking about the DVCS. We want to pick the tool up, |
| 578 | use it quickly, and then set it aside in order to get back to our actual |
| 579 | job as quickly as possible. |
| 580 | |
| 581 | Professional software developers in particular are prone to focusing on |
| 582 | feature set sizes when choosing tools because this is sometimes a highly |
| 583 | important consideration. They spend all day, every day, in their |
| 584 | favorite text editors, and time they spend learning all of the arcana of |
| 585 | their favorite programming languages is well-spent. Skills with these |
| 586 | tools are direct productivity drivers, which in turn directly drives how |
| 587 | much money a developer can make. (Or how much idle time they can afford |
| 588 | to take, which amounts to the same thing.) But if you are a professional |
| 589 | software developer, we want you to ask yourself a question: "How do I |
| 590 | get paid more by mastering arcane features of my DVCS?" Unless you have |
| 591 | a good answer to that, you probably do not want to be choosing a DVCS |
| 592 | based on how many arcane features it has. |
| 593 | |
| 594 | The argument is similar for other types of users: if you are a hobbyist, |
| 595 | how much time do you want to spend mastering your DVCS instead of on |
| 596 | the hobby supported by use of that DVCS? |
| 597 | |
| 598 | There is some minimal set of features required to achieve the purposes |
| 599 | that drive our selection of a DVCS, but there is a level beyond which |
| 600 | more features only slow us down while we're learning the tool, since we |
| 601 | must plow through documentation on features we're not likely to ever |
| 602 | use. When the number of features grows to the point where people of |
| 603 | normal motivation cannot spend the time to master them all, the tool |
| 604 | becomes <i>less</i> productive to use. |
| 605 | |
| 606 | The core developers of the Fossil project achieve a balance between feature |
| 607 | set size and ease of use by |
| 608 | carefully choosing which users to give commit bits to, then in being |
| 609 | choosy about which of the contributed feature branches to merge down to |
| 610 | trunk. We say "no" to a lot of feature proposals. |
| 611 | |
| 612 | The end result is that Fossil more closely adheres to |
| 613 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 614 | principle of least astonishment] than Git does. |
| 615 | |
| 616 | |
| 617 | <h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4> |
| 618 | |
| 619 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 620 | of changes, but Git tends to focus more on individual branches of |
| 621 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 622 | |
| 623 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -543,80 +543,11 @@ | |
| 543 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 544 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 545 | not the best way to hang a picture on the living room wall. |
| 546 | |
| 547 | |
| 548 | <h4 id="branches">2.5.3 Individual Branches vs. The Entire Change History</h4> |
| 549 | |
| 550 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 551 | of changes, but Git tends to focus more on individual branches of |
| 552 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 553 | |
| 554 |