Fossil SCM
Added a few paras to section 3.0 in rebaseharm.md, giving consequences of siloed development in Socratic fashion.
Commit
924bf44d398461d03ac1eb1ccc058928260ebe789ec61cd23c86b39186b7ddb5
Parent
cd689b3813464a4…
1 file changed
+13
+13
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -133,10 +133,23 @@ | ||
| 133 | 133 | code right before I publish it." I sympathize with this sentiment, |
| 134 | 134 | and am frequently guilty of it myself. It is humbling to display |
| 135 | 135 | your stupid mistake to the whole world on an internet that |
| 136 | 136 | never forgets. And yet, humble programmers generate better code. |
| 137 | 137 | |
| 138 | +What is the fastest path to solid code? Is it to continue staring at | |
| 139 | +your private branch to seek out every last bug, or is it to publish it | |
| 140 | +as-is, whereupon the many eyeballs will immediately see that last stupid | |
| 141 | +error in the code? Testing and development are often done by separate | |
| 142 | +groups within a larger software development organization, because | |
| 143 | +developers get too close to their own code to see every problem in it. | |
| 144 | + | |
| 145 | +Given that, is it better for those many eyeballs to find your problems | |
| 146 | +while they’re still isolated on a feature branch, or should that vetting | |
| 147 | +wait until you finally push a collapsed version of a private working | |
| 148 | +branch to the parent repo? Will the many eyeballs even see those errors | |
| 149 | +when they’re intermingled with code implementing some tasty new feature? | |
| 150 | + | |
| 138 | 151 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 139 | 152 | |
| 140 | 153 | Rebase adds new check-ins to the blockchain without giving the operator |
| 141 | 154 | an opportunity to test and verify those check-ins. Just because the |
| 142 | 155 | underlying three-way merge had no conflict does not mean that the resulting |
| 143 | 156 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -133,10 +133,23 @@ | |
| 133 | code right before I publish it." I sympathize with this sentiment, |
| 134 | and am frequently guilty of it myself. It is humbling to display |
| 135 | your stupid mistake to the whole world on an internet that |
| 136 | never forgets. And yet, humble programmers generate better code. |
| 137 | |
| 138 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 139 | |
| 140 | Rebase adds new check-ins to the blockchain without giving the operator |
| 141 | an opportunity to test and verify those check-ins. Just because the |
| 142 | underlying three-way merge had no conflict does not mean that the resulting |
| 143 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -133,10 +133,23 @@ | |
| 133 | code right before I publish it." I sympathize with this sentiment, |
| 134 | and am frequently guilty of it myself. It is humbling to display |
| 135 | your stupid mistake to the whole world on an internet that |
| 136 | never forgets. And yet, humble programmers generate better code. |
| 137 | |
| 138 | What is the fastest path to solid code? Is it to continue staring at |
| 139 | your private branch to seek out every last bug, or is it to publish it |
| 140 | as-is, whereupon the many eyeballs will immediately see that last stupid |
| 141 | error in the code? Testing and development are often done by separate |
| 142 | groups within a larger software development organization, because |
| 143 | developers get too close to their own code to see every problem in it. |
| 144 | |
| 145 | Given that, is it better for those many eyeballs to find your problems |
| 146 | while they’re still isolated on a feature branch, or should that vetting |
| 147 | wait until you finally push a collapsed version of a private working |
| 148 | branch to the parent repo? Will the many eyeballs even see those errors |
| 149 | when they’re intermingled with code implementing some tasty new feature? |
| 150 | |
| 151 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 152 | |
| 153 | Rebase adds new check-ins to the blockchain without giving the operator |
| 154 | an opportunity to test and verify those check-ins. Just because the |
| 155 | underlying three-way merge had no conflict does not mean that the resulting |
| 156 |