Fossil SCM
Minor editorial changes to rebaseharm.md, in an attempt to improve clarity and readability.
Commit
9b32c180eba0f4628c91cdff8da2f33e3b6b3055c9f3b62fbf30d775f80bbc1e
Parent
82f75864d5664a1…
1 file changed
+13
-12
+13
-12
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -1,25 +1,25 @@ | ||
| 1 | 1 | # Rebase Considered Harmful |
| 2 | 2 | |
| 3 | -Fossil deliberately does not implement "rebase", because the original | |
| 3 | +Fossil deliberately omits a "rebase" command, because the original | |
| 4 | 4 | designer of Fossil (and author of this article) considers rebase to be |
| 5 | 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | 6 | explain that point of view. |
| 7 | 7 | |
| 8 | 8 | ## 1.0 Rebasing is dangerous |
| 9 | 9 | |
| 10 | -Everyone, even the most vocal advocates of rebase, agrees that rebase can | |
| 11 | -cause problems when misused. All rebase documentation talks about the | |
| 12 | -[golden rule of rebase][golden], that it should never be used on a public | |
| 10 | +Most people, even strident advocates rebase, agree that rebase can | |
| 11 | +cause problems when misused. Rebase documentation talks about the | |
| 12 | +[golden rule of rebase][golden]: that it should never be used on a public | |
| 13 | 13 | branch. Horror stories of misused rebase abound, and the rebase |
| 14 | -documentation devotes considerable space to hints on how to recover from | |
| 15 | -rebase errors and/or misuse. | |
| 14 | +documentation devotes considerable space toward explaining how to | |
| 15 | +recover from rebase errors and/or misuse. | |
| 16 | 16 | |
| 17 | 17 | Sometimes sharp and dangerous tools are justified, |
| 18 | 18 | because they accomplish things that cannot be |
| 19 | -(easily) done otherwise. But rebase does not fall into that category. | |
| 20 | -It provides no new capabilities, as we shall see in the next section: | |
| 19 | +(easily) done otherwise. But rebase does not fall into that category, | |
| 20 | +because rebase provides no new capabilities. To wit: | |
| 21 | 21 | |
| 22 | 22 | ## 2.0 A rebase is just a merge with historical references omitted |
| 23 | 23 | |
| 24 | 24 | A rebase is really nothing more than a merge (or a series of merges) |
| 25 | 25 | that deliberately forgets one of the parents of each merge step. |
| @@ -45,11 +45,11 @@ | ||
| 45 | 45 | capabilities are weak and need active assistance from the user to |
| 46 | 46 | keep things manageable. |
| 47 | 47 | Surely a better approach is to record |
| 48 | 48 | the complete ancestry of every check-in but then fix the tool to show |
| 49 | 49 | a "clean" history in those instances where a simplified display is |
| 50 | -desirable and edifying, but retaining the option to show the real, | |
| 50 | +desirable and edifying, but retain the option to show the real, | |
| 51 | 51 | complete, messy history for cases where detail and accuracy are more |
| 52 | 52 | important. |
| 53 | 53 | |
| 54 | 54 | So, another way of thinking about rebase is that it is a kind of |
| 55 | 55 | merge that intentionally forgets some details in order to |
| @@ -114,12 +114,13 @@ | ||
| 114 | 114 | with collaborators. This is not good for product quality. |
| 115 | 115 | |
| 116 | 116 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 117 | 117 | that best predictor of bugs is the distance on the org-chart between |
| 118 | 118 | the stake-holders. Or, bugs are reduced when the engineers talk to |
| 119 | -one another. Similar finds arise in other disciplines. Keeping | |
| 120 | -private branches is a key symptom of siloing. | |
| 119 | +one another. Similar findings arise in other disciplines. Keeping | |
| 120 | +private branches does not prove that developers are communicating | |
| 121 | +insufficiently, but it is a key symptom that problem. | |
| 121 | 122 | |
| 122 | 123 | [Weinberg][weinberg] argues programming should be "egoless". That |
| 123 | 124 | is to say, programmers should avoid linking their code with their sense of |
| 124 | 125 | self, as that makes it more difficult for them to find and respond |
| 125 | 126 | to bugs, and hence makes them less productive. Many developers are |
| @@ -218,11 +219,11 @@ | ||
| 218 | 219 | before it is committed to the blockchain |
| 219 | 220 | |
| 220 | 221 | 3. Cherry-pick merges are "safe" in the sense that they do not |
| 221 | 222 | cause problems for collaborators if you do them on public branches. |
| 222 | 223 | |
| 223 | - 4. Cherry-picks preserve both the original and the revised check-ins, | |
| 224 | + 4. Cherry-picks keep both the original and the revised check-ins, | |
| 224 | 225 | so both timestamps are preserved. |
| 225 | 226 | |
| 226 | 227 | ## 8.0 Summary and conclusion |
| 227 | 228 | |
| 228 | 229 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 229 | 230 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,25 +1,25 @@ | |
| 1 | # Rebase Considered Harmful |
| 2 | |
| 3 | Fossil deliberately does not implement "rebase", because the original |
| 4 | designer of Fossil (and author of this article) considers rebase to be |
| 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | explain that point of view. |
| 7 | |
| 8 | ## 1.0 Rebasing is dangerous |
| 9 | |
| 10 | Everyone, even the most vocal advocates of rebase, agrees that rebase can |
| 11 | cause problems when misused. All rebase documentation talks about the |
| 12 | [golden rule of rebase][golden], that it should never be used on a public |
| 13 | branch. Horror stories of misused rebase abound, and the rebase |
| 14 | documentation devotes considerable space to hints on how to recover from |
| 15 | rebase errors and/or misuse. |
| 16 | |
| 17 | Sometimes sharp and dangerous tools are justified, |
| 18 | because they accomplish things that cannot be |
| 19 | (easily) done otherwise. But rebase does not fall into that category. |
| 20 | It provides no new capabilities, as we shall see in the next section: |
| 21 | |
| 22 | ## 2.0 A rebase is just a merge with historical references omitted |
| 23 | |
| 24 | A rebase is really nothing more than a merge (or a series of merges) |
| 25 | that deliberately forgets one of the parents of each merge step. |
| @@ -45,11 +45,11 @@ | |
| 45 | capabilities are weak and need active assistance from the user to |
| 46 | keep things manageable. |
| 47 | Surely a better approach is to record |
| 48 | the complete ancestry of every check-in but then fix the tool to show |
| 49 | a "clean" history in those instances where a simplified display is |
| 50 | desirable and edifying, but retaining the option to show the real, |
| 51 | complete, messy history for cases where detail and accuracy are more |
| 52 | important. |
| 53 | |
| 54 | So, another way of thinking about rebase is that it is a kind of |
| 55 | merge that intentionally forgets some details in order to |
| @@ -114,12 +114,13 @@ | |
| 114 | with collaborators. This is not good for product quality. |
| 115 | |
| 116 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 117 | that best predictor of bugs is the distance on the org-chart between |
| 118 | the stake-holders. Or, bugs are reduced when the engineers talk to |
| 119 | one another. Similar finds arise in other disciplines. Keeping |
| 120 | private branches is a key symptom of siloing. |
| 121 | |
| 122 | [Weinberg][weinberg] argues programming should be "egoless". That |
| 123 | is to say, programmers should avoid linking their code with their sense of |
| 124 | self, as that makes it more difficult for them to find and respond |
| 125 | to bugs, and hence makes them less productive. Many developers are |
| @@ -218,11 +219,11 @@ | |
| 218 | before it is committed to the blockchain |
| 219 | |
| 220 | 3. Cherry-pick merges are "safe" in the sense that they do not |
| 221 | cause problems for collaborators if you do them on public branches. |
| 222 | |
| 223 | 4. Cherry-picks preserve both the original and the revised check-ins, |
| 224 | so both timestamps are preserved. |
| 225 | |
| 226 | ## 8.0 Summary and conclusion |
| 227 | |
| 228 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 229 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,25 +1,25 @@ | |
| 1 | # Rebase Considered Harmful |
| 2 | |
| 3 | Fossil deliberately omits a "rebase" command, because the original |
| 4 | designer of Fossil (and author of this article) considers rebase to be |
| 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | explain that point of view. |
| 7 | |
| 8 | ## 1.0 Rebasing is dangerous |
| 9 | |
| 10 | Most people, even strident advocates rebase, agree that rebase can |
| 11 | cause problems when misused. Rebase documentation talks about the |
| 12 | [golden rule of rebase][golden]: that it should never be used on a public |
| 13 | branch. Horror stories of misused rebase abound, and the rebase |
| 14 | documentation devotes considerable space toward explaining how to |
| 15 | recover from rebase errors and/or misuse. |
| 16 | |
| 17 | Sometimes sharp and dangerous tools are justified, |
| 18 | because they accomplish things that cannot be |
| 19 | (easily) done otherwise. But rebase does not fall into that category, |
| 20 | because rebase provides no new capabilities. To wit: |
| 21 | |
| 22 | ## 2.0 A rebase is just a merge with historical references omitted |
| 23 | |
| 24 | A rebase is really nothing more than a merge (or a series of merges) |
| 25 | that deliberately forgets one of the parents of each merge step. |
| @@ -45,11 +45,11 @@ | |
| 45 | capabilities are weak and need active assistance from the user to |
| 46 | keep things manageable. |
| 47 | Surely a better approach is to record |
| 48 | the complete ancestry of every check-in but then fix the tool to show |
| 49 | a "clean" history in those instances where a simplified display is |
| 50 | desirable and edifying, but retain the option to show the real, |
| 51 | complete, messy history for cases where detail and accuracy are more |
| 52 | important. |
| 53 | |
| 54 | So, another way of thinking about rebase is that it is a kind of |
| 55 | merge that intentionally forgets some details in order to |
| @@ -114,12 +114,13 @@ | |
| 114 | with collaborators. This is not good for product quality. |
| 115 | |
| 116 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 117 | that best predictor of bugs is the distance on the org-chart between |
| 118 | the stake-holders. Or, bugs are reduced when the engineers talk to |
| 119 | one another. Similar findings arise in other disciplines. Keeping |
| 120 | private branches does not prove that developers are communicating |
| 121 | insufficiently, but it is a key symptom that problem. |
| 122 | |
| 123 | [Weinberg][weinberg] argues programming should be "egoless". That |
| 124 | is to say, programmers should avoid linking their code with their sense of |
| 125 | self, as that makes it more difficult for them to find and respond |
| 126 | to bugs, and hence makes them less productive. Many developers are |
| @@ -218,11 +219,11 @@ | |
| 219 | before it is committed to the blockchain |
| 220 | |
| 221 | 3. Cherry-pick merges are "safe" in the sense that they do not |
| 222 | cause problems for collaborators if you do them on public branches. |
| 223 | |
| 224 | 4. Cherry-picks keep both the original and the revised check-ins, |
| 225 | so both timestamps are preserved. |
| 226 | |
| 227 | ## 8.0 Summary and conclusion |
| 228 | |
| 229 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 230 |