Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Added a few paras to section 3.0 in rebaseharm.md, giving consequences of siloed development in Socratic fashion. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
924bf44d398461d03ac1eb1ccc058928 |
| User & Date: | wyoung 2019-09-13 09:25:05 |
Context
|
2019-09-13
| ||
| 10:46 | Added section "2.8 Test Before Commit" to the fossil-v-git doc. check-in: e5ba45788b user: wyoung tags: trunk | |
| 09:25 | Added a few paras to section 3.0 in rebaseharm.md, giving consequences of siloed development in Socratic fashion. check-in: 924bf44d39 user: wyoung tags: trunk | |
| 09:23 | Assorted grammar and spelling fixes in www/rebaseharm.md. Also added named anchors to all of the sections. check-in: cd689b3813 user: wyoung tags: trunk | |
Changes
Changes to www/rebaseharm.md.
131 132 133 134 135 136 137 138 139 140 141 142 143 144 |
to bugs, and hence makes them less productive. Many developers are drawn to private branches out of sense of ego. "I want to get the code right before I publish it." I sympathize with this sentiment, and am frequently guilty of it myself. It is humbling to display your stupid mistake to the whole world on an internet that never forgets. And yet, humble programmers generate better code. ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain Rebase adds new check-ins to the blockchain without giving the operator an opportunity to test and verify those check-ins. Just because the underlying three-way merge had no conflict does not mean that the resulting code actually works. Thus, rebase runs the very real risk of adding non-functional check-ins to the permanent record. |
> > > > > > > > > > > > > |
131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 |
to bugs, and hence makes them less productive. Many developers are drawn to private branches out of sense of ego. "I want to get the code right before I publish it." I sympathize with this sentiment, and am frequently guilty of it myself. It is humbling to display your stupid mistake to the whole world on an internet that never forgets. And yet, humble programmers generate better code. What is the fastest path to solid code? Is it to continue staring at your private branch to seek out every last bug, or is it to publish it as-is, whereupon the many eyeballs will immediately see that last stupid error in the code? Testing and development are often done by separate groups within a larger software development organization, because developers get too close to their own code to see every problem in it. Given that, is it better for those many eyeballs to find your problems while they’re still isolated on a feature branch, or should that vetting wait until you finally push a collapsed version of a private working branch to the parent repo? Will the many eyeballs even see those errors when they’re intermingled with code implementing some tasty new feature? ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain Rebase adds new check-ins to the blockchain without giving the operator an opportunity to test and verify those check-ins. Just because the underlying three-way merge had no conflict does not mean that the resulting code actually works. Thus, rebase runs the very real risk of adding non-functional check-ins to the permanent record. |