Fossil SCM
Assorted grammar and spelling fixes in www/rebaseharm.md. Also added named anchors to all of the sections.
Commit
cd689b3813464a41d1bfb3f0879960b9a1c18f1c0a268094ffddf0a03c31af68
Parent
29997f803b4c14c…
1 file changed
+22
-17
+22
-17
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -1,27 +1,32 @@ | ||
| 1 | 1 | # Rebase Considered Harmful |
| 2 | 2 | |
| 3 | 3 | Fossil deliberately omits a "rebase" command, because the original |
| 4 | -designer of Fossil (and author of this article) considers rebase to be | |
| 4 | +designer of Fossil (and [original author][vhist] 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 | +[vhist]: https://fossil-scm.org/fossil/finfo?name=www/rebaseharm.md | |
| 9 | + | |
| 8 | 10 | ## 1.0 Rebasing is dangerous |
| 9 | 11 | |
| 10 | -Most people, even strident advocates rebase, agree that rebase can | |
| 11 | -cause problems when misused. Rebase documentation talks about the | |
| 12 | +Most people, even strident advocates of rebase, agree that rebase can | |
| 13 | +cause problems when misused. The Git rebase documentation talks about the | |
| 12 | 14 | [golden rule of rebase][golden]: that it should never be used on a public |
| 13 | 15 | branch. Horror stories of misused rebase abound, and the rebase |
| 14 | 16 | documentation devotes considerable space toward explaining how to |
| 15 | 17 | recover from rebase errors and/or misuse. |
| 16 | 18 | |
| 19 | +## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities | |
| 20 | + | |
| 17 | 21 | Sometimes sharp and dangerous tools are justified, |
| 18 | 22 | 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: | |
| 23 | +done otherwise, or at least cannot be done easily. | |
| 24 | +Rebase does not fall into that category, | |
| 25 | +because it provides no new capabilities. | |
| 21 | 26 | |
| 22 | -## 2.0 A rebase is just a merge with historical references omitted | |
| 27 | +### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted | |
| 23 | 28 | |
| 24 | 29 | A rebase is really nothing more than a merge (or a series of merges) |
| 25 | 30 | that deliberately forgets one of the parents of each merge step. |
| 26 | 31 | To help illustrate this fact, |
| 27 | 32 | consider the first rebase example from the |
| @@ -38,11 +43,11 @@ | ||
| 38 | 43 | records the fact that C4 is its merge parent but C4\' does not. |
| 39 | 44 | |
| 40 | 45 | Thus, a rebase is just a merge that forgets where it came from. |
| 41 | 46 | |
| 42 | 47 | The Git documentation acknowledges this fact (in so many words) and |
| 43 | -justifies it by saying "rebas[e] makes for a cleaner history". I read | |
| 48 | +justifies it by saying "rebasing makes for a cleaner history." I read | |
| 44 | 49 | that sentence as a tacit admission that the Git history display |
| 45 | 50 | capabilities are weak and need active assistance from the user to |
| 46 | 51 | keep things manageable. |
| 47 | 52 | Surely a better approach is to record |
| 48 | 53 | the complete ancestry of every check-in but then fix the tool to show |
| @@ -53,11 +58,11 @@ | ||
| 53 | 58 | |
| 54 | 59 | So, another way of thinking about rebase is that it is a kind of |
| 55 | 60 | merge that intentionally forgets some details in order to |
| 56 | 61 | not overwhelm the weak history display mechanisms available in Git. |
| 57 | 62 | |
| 58 | -### 2.1 Rebase does not actually provide better feature-branch diffs | |
| 63 | +### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs | |
| 59 | 64 | |
| 60 | 65 | Another argument, often cited, is that rebasing a feature branch |
| 61 | 66 | allows one to see just the changes in the feature branch without |
| 62 | 67 | the concurrent changes in the main line of development. |
| 63 | 68 | Consider a hypothetical case: |
| @@ -103,11 +108,11 @@ | ||
| 103 | 108 | |
| 104 | 109 | So, to help with the problem of viewing changes associated with a feature |
| 105 | 110 | branch, perhaps what is needed is not rebase but rather better tools to |
| 106 | 111 | help users identify an appropriate baseline for their diffs. |
| 107 | 112 | |
| 108 | -## 3.0 Rebase encourages siloed development | |
| 113 | +## <a name="siloing"></a>3.0 Rebase encourages siloed development | |
| 109 | 114 | |
| 110 | 115 | The [golden rule of rebase][golden] is that you should never do it |
| 111 | 116 | on public branches, so if you are using rebase as intended, that means |
| 112 | 117 | you are keeping private branches. Or, to put it another way, you are |
| 113 | 118 | doing siloed development. You are not sharing your intermediate work |
| @@ -118,21 +123,21 @@ | ||
| 118 | 123 | the stake-holders. Or, bugs are reduced when the engineers talk to |
| 119 | 124 | one another. Similar findings arise in other disciplines. Keeping |
| 120 | 125 | private branches does not prove that developers are communicating |
| 121 | 126 | insufficiently, but it is a key symptom that problem. |
| 122 | 127 | |
| 123 | -[Weinberg][weinberg] argues programming should be "egoless". That | |
| 128 | +[Weinberg][weinberg] argues programming should be "egoless." That | |
| 124 | 129 | is to say, programmers should avoid linking their code with their sense of |
| 125 | 130 | self, as that makes it more difficult for them to find and respond |
| 126 | 131 | to bugs, and hence makes them less productive. Many developers are |
| 127 | 132 | drawn to private branches out of sense of ego. "I want to get the |
| 128 | -code right before I publish it". I sympathize with this sentiment, | |
| 133 | +code right before I publish it." I sympathize with this sentiment, | |
| 129 | 134 | and am frequently guilty of it myself. It is humbling to display |
| 130 | 135 | your stupid mistake to the whole world on an internet that |
| 131 | 136 | never forgets. And yet, humble programmers generate better code. |
| 132 | 137 | |
| 133 | -## 4.0 Rebase commits untested check-ins to the blockchain | |
| 138 | +## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain | |
| 134 | 139 | |
| 135 | 140 | Rebase adds new check-ins to the blockchain without giving the operator |
| 136 | 141 | an opportunity to test and verify those check-ins. Just because the |
| 137 | 142 | underlying three-way merge had no conflict does not mean that the resulting |
| 138 | 143 | code actually works. Thus, rebase runs the very real risk of adding |
| @@ -145,11 +150,11 @@ | ||
| 145 | 150 | and a chance to back out or fix the change if it is broken, without leaving |
| 146 | 151 | busted check-ins on the blockchain to complicate future bisects. |
| 147 | 152 | |
| 148 | 153 | With rebase, pre-commit testing is not an option. |
| 149 | 154 | |
| 150 | -## 5.0 Rebase causes timestamp confusion | |
| 155 | +## <a name="timestamps"></a>5.0 Rebase causes timestamp confusion | |
| 151 | 156 | |
| 152 | 157 | Consider the earlier example of rebasing a feature branch: |
| 153 | 158 | |
| 154 | 159 |  |
| 155 | 160 | |
| @@ -162,11 +167,11 @@ | ||
| 162 | 167 | unique timestamps for C3' and C5'. But then you lose the information |
| 163 | 168 | about when those check-ins were originally created, which can make |
| 164 | 169 | historical analysis of changes more difficult, and might also |
| 165 | 170 | complicate prior art claims. |
| 166 | 171 | |
| 167 | -## 6.0 Rebasing is the same as lying | |
| 172 | +## <a name="lying"></a>6.0 Rebasing is the same as lying | |
| 168 | 173 | |
| 169 | 174 | By discarding parentage information, rebase attempts to deceive the |
| 170 | 175 | reader about how the code actually came together. |
| 171 | 176 | |
| 172 | 177 | The [Git rebase documentation][gitrebase] admits as much. They acknowledge |
| @@ -180,11 +185,11 @@ | ||
| 180 | 185 | book, and the manual for how to maintain your software deserves careful |
| 181 | 186 | editing. This is the camp that uses tools like rebase and filter-branch |
| 182 | 187 | to tell the story in the way that’s best for future readers."_ |
| 183 | 188 | |
| 184 | 189 | I reject this argument utterly. |
| 185 | -Unless you project is a work of fiction, it is not a "story" but a "history". | |
| 190 | +Unless your project is a work of fiction, it is not a "story" but a "history." | |
| 186 | 191 | Honorable writers adjust their narrative to fit |
| 187 | 192 | history. Rebase adjusts history to fit the narrative. |
| 188 | 193 | |
| 189 | 194 | Truthful texts can be redrafted for clarity and accuracy. |
| 190 | 195 | Fossil supports this by providing mechanisms to fix |
| @@ -202,11 +207,11 @@ | ||
| 202 | 207 | or clarifications to historical check-ins in its blockchain. Hence, |
| 203 | 208 | once again, rebase can be seen as an attempt to work around limitations |
| 204 | 209 | of Git. Wouldn't it be better to fix the tool rather than to lie about |
| 205 | 210 | the project history? |
| 206 | 211 | |
| 207 | -## 7.0 Cherry-pick merges work better then rebase | |
| 212 | +## <a name="better-plan"></a>7.0 Cherry-pick merges work better than rebase | |
| 208 | 213 | |
| 209 | 214 | Perhaps there are some cases where a rebase-like transformation |
| 210 | 215 | is actually helpful. But those cases are rare. And when they do |
| 211 | 216 | come up, running a series of cherry-pick merges achieve the same |
| 212 | 217 | topology, but with advantages: |
| @@ -222,11 +227,11 @@ | ||
| 222 | 227 | cause problems for collaborators if you do them on public branches. |
| 223 | 228 | |
| 224 | 229 | 4. Cherry-picks keep both the original and the revised check-ins, |
| 225 | 230 | so both timestamps are preserved. |
| 226 | 231 | |
| 227 | -## 8.0 Summary and conclusion | |
| 232 | +## <a name="conclusion"></a>8.0 Summary and conclusion | |
| 228 | 233 | |
| 229 | 234 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 230 | 235 | omits historical information. It causes problems for collaboration. |
| 231 | 236 | And it has no offsetting benefits. |
| 232 | 237 | |
| 233 | 238 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,27 +1,32 @@ | |
| 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. |
| 26 | To help illustrate this fact, |
| 27 | consider the first rebase example from the |
| @@ -38,11 +43,11 @@ | |
| 38 | records the fact that C4 is its merge parent but C4\' does not. |
| 39 | |
| 40 | Thus, a rebase is just a merge that forgets where it came from. |
| 41 | |
| 42 | The Git documentation acknowledges this fact (in so many words) and |
| 43 | justifies it by saying "rebas[e] makes for a cleaner history". I read |
| 44 | that sentence as a tacit admission that the Git history display |
| 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 |
| @@ -53,11 +58,11 @@ | |
| 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 |
| 56 | not overwhelm the weak history display mechanisms available in Git. |
| 57 | |
| 58 | ### 2.1 Rebase does not actually provide better feature-branch diffs |
| 59 | |
| 60 | Another argument, often cited, is that rebasing a feature branch |
| 61 | allows one to see just the changes in the feature branch without |
| 62 | the concurrent changes in the main line of development. |
| 63 | Consider a hypothetical case: |
| @@ -103,11 +108,11 @@ | |
| 103 | |
| 104 | So, to help with the problem of viewing changes associated with a feature |
| 105 | branch, perhaps what is needed is not rebase but rather better tools to |
| 106 | help users identify an appropriate baseline for their diffs. |
| 107 | |
| 108 | ## 3.0 Rebase encourages siloed development |
| 109 | |
| 110 | The [golden rule of rebase][golden] is that you should never do it |
| 111 | on public branches, so if you are using rebase as intended, that means |
| 112 | you are keeping private branches. Or, to put it another way, you are |
| 113 | doing siloed development. You are not sharing your intermediate work |
| @@ -118,21 +123,21 @@ | |
| 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 |
| 127 | drawn to private branches out of sense of ego. "I want to get the |
| 128 | code right before I publish it". I sympathize with this sentiment, |
| 129 | and am frequently guilty of it myself. It is humbling to display |
| 130 | your stupid mistake to the whole world on an internet that |
| 131 | never forgets. And yet, humble programmers generate better code. |
| 132 | |
| 133 | ## 4.0 Rebase commits untested check-ins to the blockchain |
| 134 | |
| 135 | Rebase adds new check-ins to the blockchain without giving the operator |
| 136 | an opportunity to test and verify those check-ins. Just because the |
| 137 | underlying three-way merge had no conflict does not mean that the resulting |
| 138 | code actually works. Thus, rebase runs the very real risk of adding |
| @@ -145,11 +150,11 @@ | |
| 145 | and a chance to back out or fix the change if it is broken, without leaving |
| 146 | busted check-ins on the blockchain to complicate future bisects. |
| 147 | |
| 148 | With rebase, pre-commit testing is not an option. |
| 149 | |
| 150 | ## 5.0 Rebase causes timestamp confusion |
| 151 | |
| 152 | Consider the earlier example of rebasing a feature branch: |
| 153 | |
| 154 |  |
| 155 | |
| @@ -162,11 +167,11 @@ | |
| 162 | unique timestamps for C3' and C5'. But then you lose the information |
| 163 | about when those check-ins were originally created, which can make |
| 164 | historical analysis of changes more difficult, and might also |
| 165 | complicate prior art claims. |
| 166 | |
| 167 | ## 6.0 Rebasing is the same as lying |
| 168 | |
| 169 | By discarding parentage information, rebase attempts to deceive the |
| 170 | reader about how the code actually came together. |
| 171 | |
| 172 | The [Git rebase documentation][gitrebase] admits as much. They acknowledge |
| @@ -180,11 +185,11 @@ | |
| 180 | book, and the manual for how to maintain your software deserves careful |
| 181 | editing. This is the camp that uses tools like rebase and filter-branch |
| 182 | to tell the story in the way that’s best for future readers."_ |
| 183 | |
| 184 | I reject this argument utterly. |
| 185 | Unless you project is a work of fiction, it is not a "story" but a "history". |
| 186 | Honorable writers adjust their narrative to fit |
| 187 | history. Rebase adjusts history to fit the narrative. |
| 188 | |
| 189 | Truthful texts can be redrafted for clarity and accuracy. |
| 190 | Fossil supports this by providing mechanisms to fix |
| @@ -202,11 +207,11 @@ | |
| 202 | or clarifications to historical check-ins in its blockchain. Hence, |
| 203 | once again, rebase can be seen as an attempt to work around limitations |
| 204 | of Git. Wouldn't it be better to fix the tool rather than to lie about |
| 205 | the project history? |
| 206 | |
| 207 | ## 7.0 Cherry-pick merges work better then rebase |
| 208 | |
| 209 | Perhaps there are some cases where a rebase-like transformation |
| 210 | is actually helpful. But those cases are rare. And when they do |
| 211 | come up, running a series of cherry-pick merges achieve the same |
| 212 | topology, but with advantages: |
| @@ -222,11 +227,11 @@ | |
| 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 | omits historical information. It causes problems for collaboration. |
| 231 | And it has no offsetting benefits. |
| 232 | |
| 233 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,27 +1,32 @@ | |
| 1 | # Rebase Considered Harmful |
| 2 | |
| 3 | Fossil deliberately omits a "rebase" command, because the original |
| 4 | designer of Fossil (and [original author][vhist] 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 | [vhist]: https://fossil-scm.org/fossil/finfo?name=www/rebaseharm.md |
| 9 | |
| 10 | ## 1.0 Rebasing is dangerous |
| 11 | |
| 12 | Most people, even strident advocates of rebase, agree that rebase can |
| 13 | cause problems when misused. The Git rebase documentation talks about the |
| 14 | [golden rule of rebase][golden]: that it should never be used on a public |
| 15 | branch. Horror stories of misused rebase abound, and the rebase |
| 16 | documentation devotes considerable space toward explaining how to |
| 17 | recover from rebase errors and/or misuse. |
| 18 | |
| 19 | ## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities |
| 20 | |
| 21 | Sometimes sharp and dangerous tools are justified, |
| 22 | because they accomplish things that cannot be |
| 23 | done otherwise, or at least cannot be done easily. |
| 24 | Rebase does not fall into that category, |
| 25 | because it provides no new capabilities. |
| 26 | |
| 27 | ### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted |
| 28 | |
| 29 | A rebase is really nothing more than a merge (or a series of merges) |
| 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | To help illustrate this fact, |
| 32 | consider the first rebase example from the |
| @@ -38,11 +43,11 @@ | |
| 43 | records the fact that C4 is its merge parent but C4\' does not. |
| 44 | |
| 45 | Thus, a rebase is just a merge that forgets where it came from. |
| 46 | |
| 47 | The Git documentation acknowledges this fact (in so many words) and |
| 48 | justifies it by saying "rebasing makes for a cleaner history." I read |
| 49 | that sentence as a tacit admission that the Git history display |
| 50 | capabilities are weak and need active assistance from the user to |
| 51 | keep things manageable. |
| 52 | Surely a better approach is to record |
| 53 | the complete ancestry of every check-in but then fix the tool to show |
| @@ -53,11 +58,11 @@ | |
| 58 | |
| 59 | So, another way of thinking about rebase is that it is a kind of |
| 60 | merge that intentionally forgets some details in order to |
| 61 | not overwhelm the weak history display mechanisms available in Git. |
| 62 | |
| 63 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 64 | |
| 65 | Another argument, often cited, is that rebasing a feature branch |
| 66 | allows one to see just the changes in the feature branch without |
| 67 | the concurrent changes in the main line of development. |
| 68 | Consider a hypothetical case: |
| @@ -103,11 +108,11 @@ | |
| 108 | |
| 109 | So, to help with the problem of viewing changes associated with a feature |
| 110 | branch, perhaps what is needed is not rebase but rather better tools to |
| 111 | help users identify an appropriate baseline for their diffs. |
| 112 | |
| 113 | ## <a name="siloing"></a>3.0 Rebase encourages siloed development |
| 114 | |
| 115 | The [golden rule of rebase][golden] is that you should never do it |
| 116 | on public branches, so if you are using rebase as intended, that means |
| 117 | you are keeping private branches. Or, to put it another way, you are |
| 118 | doing siloed development. You are not sharing your intermediate work |
| @@ -118,21 +123,21 @@ | |
| 123 | the stake-holders. Or, bugs are reduced when the engineers talk to |
| 124 | one another. Similar findings arise in other disciplines. Keeping |
| 125 | private branches does not prove that developers are communicating |
| 126 | insufficiently, but it is a key symptom that problem. |
| 127 | |
| 128 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 129 | is to say, programmers should avoid linking their code with their sense of |
| 130 | self, as that makes it more difficult for them to find and respond |
| 131 | to bugs, and hence makes them less productive. Many developers are |
| 132 | drawn to private branches out of sense of ego. "I want to get the |
| 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 | code actually works. Thus, rebase runs the very real risk of adding |
| @@ -145,11 +150,11 @@ | |
| 150 | and a chance to back out or fix the change if it is broken, without leaving |
| 151 | busted check-ins on the blockchain to complicate future bisects. |
| 152 | |
| 153 | With rebase, pre-commit testing is not an option. |
| 154 | |
| 155 | ## <a name="timestamps"></a>5.0 Rebase causes timestamp confusion |
| 156 | |
| 157 | Consider the earlier example of rebasing a feature branch: |
| 158 | |
| 159 |  |
| 160 | |
| @@ -162,11 +167,11 @@ | |
| 167 | unique timestamps for C3' and C5'. But then you lose the information |
| 168 | about when those check-ins were originally created, which can make |
| 169 | historical analysis of changes more difficult, and might also |
| 170 | complicate prior art claims. |
| 171 | |
| 172 | ## <a name="lying"></a>6.0 Rebasing is the same as lying |
| 173 | |
| 174 | By discarding parentage information, rebase attempts to deceive the |
| 175 | reader about how the code actually came together. |
| 176 | |
| 177 | The [Git rebase documentation][gitrebase] admits as much. They acknowledge |
| @@ -180,11 +185,11 @@ | |
| 185 | book, and the manual for how to maintain your software deserves careful |
| 186 | editing. This is the camp that uses tools like rebase and filter-branch |
| 187 | to tell the story in the way that’s best for future readers."_ |
| 188 | |
| 189 | I reject this argument utterly. |
| 190 | Unless your project is a work of fiction, it is not a "story" but a "history." |
| 191 | Honorable writers adjust their narrative to fit |
| 192 | history. Rebase adjusts history to fit the narrative. |
| 193 | |
| 194 | Truthful texts can be redrafted for clarity and accuracy. |
| 195 | Fossil supports this by providing mechanisms to fix |
| @@ -202,11 +207,11 @@ | |
| 207 | or clarifications to historical check-ins in its blockchain. Hence, |
| 208 | once again, rebase can be seen as an attempt to work around limitations |
| 209 | of Git. Wouldn't it be better to fix the tool rather than to lie about |
| 210 | the project history? |
| 211 | |
| 212 | ## <a name="better-plan"></a>7.0 Cherry-pick merges work better than rebase |
| 213 | |
| 214 | Perhaps there are some cases where a rebase-like transformation |
| 215 | is actually helpful. But those cases are rare. And when they do |
| 216 | come up, running a series of cherry-pick merges achieve the same |
| 217 | topology, but with advantages: |
| @@ -222,11 +227,11 @@ | |
| 227 | cause problems for collaborators if you do them on public branches. |
| 228 | |
| 229 | 4. Cherry-picks keep both the original and the revised check-ins, |
| 230 | so both timestamps are preserved. |
| 231 | |
| 232 | ## <a name="conclusion"></a>8.0 Summary and conclusion |
| 233 | |
| 234 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 235 | omits historical information. It causes problems for collaboration. |
| 236 | And it has no offsetting benefits. |
| 237 | |
| 238 |