Fossil SCM
Fixed a few spelling and grammar errors in www/rebaseharm.md
Commit
708696d88ae4935ecc6bebaa60e874d9037f539ab6bb9f009dba954e964fa088
Parent
1ff41ddaea182cf…
1 file changed
+7
-7
+7
-7
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -104,11 +104,11 @@ | ||
| 104 | 104 | |
| 105 | 105 | The argument from rebase advocates |
| 106 | 106 | is that with merge it is difficult to see only the changes associated |
| 107 | 107 | with the feature branch without the commingled mainline changes. |
| 108 | 108 | In other words, diff(C2,C7) shows changes associated both the feature |
| 109 | -branch and from the mainline, where as in the rebase case | |
| 109 | +branch and from the mainline, whereas in the rebase case | |
| 110 | 110 | diff(C6,C5\') should only the feature branch changes. |
| 111 | 111 | |
| 112 | 112 | But that argument is comparing apples to oranges, since the two diffs |
| 113 | 113 | do not have the same baseline. The correct way to see only the feature |
| 114 | 114 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| @@ -117,22 +117,22 @@ | ||
| 117 | 117 | <tr><th>Rebase<th>Merge<th>What You See |
| 118 | 118 | <tr><td>diff(C2,C5\')<td>diff(C2,C7)<td>Commingled branch and mainline changes |
| 119 | 119 | <tr><td>diff(C6,C5\')<td>diff(C6,C7)<td>Branch changes only |
| 120 | 120 | </table></center> |
| 121 | 121 | |
| 122 | -Remember: C7 and C5\' are bit-for-bit identical. So the output of the | |
| 123 | -diff is not determined by whether your select C7 or C5\' as the target | |
| 122 | +Remember: C7 and C5\' are bit-for-bit identical, so the output of the | |
| 123 | +diff is not determined by whether you select C7 or C5\' as the target | |
| 124 | 124 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 125 | 125 | |
| 126 | -So to help with the problem of viewing changes associated with a feature | |
| 126 | +So, to help with the problem of viewing changes associated with a feature | |
| 127 | 127 | branch, perhaps what is needed is not rebase but rather better tools to |
| 128 | 128 | help users identify an appropriate baseline for their diffs. |
| 129 | 129 | |
| 130 | 130 | ## 3.0 Rebase encourages siloed development |
| 131 | 131 | |
| 132 | 132 | The [golden rule of rebase][golden] is that you should never do it |
| 133 | -on public branches. So if you are using rebase as intended, that means | |
| 133 | +on public branches, so if you are using rebase as intended, that means | |
| 134 | 134 | you are keeping private branches. Or, to put it another way, you are |
| 135 | 135 | doing siloed development. You are not sharing your intermediate work |
| 136 | 136 | with collaborators. This is not good for product quality. |
| 137 | 137 | |
| 138 | 138 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| @@ -224,11 +224,11 @@ | ||
| 224 | 224 | on the first draft. |
| 225 | 225 | |
| 226 | 226 | Unfortunately, Git does not provide the ability to add corrections |
| 227 | 227 | or clarifications to historical check-ins in its blockchain. Hence, |
| 228 | 228 | once again, rebase can be seen as an attempt to work around limitations |
| 229 | -of Git. Wouldn't it be better to fix the tool rather that to lie about | |
| 229 | +of Git. Wouldn't it be better to fix the tool rather than to lie about | |
| 230 | 230 | the project history? |
| 231 | 231 | |
| 232 | 232 | ## 7.0 Cherry-pick merges work better then rebase |
| 233 | 233 | |
| 234 | 234 | Perhaps there some cases where a rebase-like transformation |
| @@ -247,11 +247,11 @@ | ||
| 247 | 247 | cause problems for collaborators if you do them on public branches. |
| 248 | 248 | |
| 249 | 249 | 4. Cherry-picks preserve both the original and the revised check-ins, |
| 250 | 250 | so both timestamps are preserved. |
| 251 | 251 | |
| 252 | -## 8.0 Summary And Conclusion | |
| 252 | +## 8.0 Summary and conclusion | |
| 253 | 253 | |
| 254 | 254 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 255 | 255 | omits historical information. It causes problems for collaboration. |
| 256 | 256 | And it has no offsetting benefits. |
| 257 | 257 | |
| 258 | 258 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -104,11 +104,11 @@ | |
| 104 | |
| 105 | The argument from rebase advocates |
| 106 | is that with merge it is difficult to see only the changes associated |
| 107 | with the feature branch without the commingled mainline changes. |
| 108 | In other words, diff(C2,C7) shows changes associated both the feature |
| 109 | branch and from the mainline, where as in the rebase case |
| 110 | diff(C6,C5\') should only the feature branch changes. |
| 111 | |
| 112 | But that argument is comparing apples to oranges, since the two diffs |
| 113 | do not have the same baseline. The correct way to see only the feature |
| 114 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| @@ -117,22 +117,22 @@ | |
| 117 | <tr><th>Rebase<th>Merge<th>What You See |
| 118 | <tr><td>diff(C2,C5\')<td>diff(C2,C7)<td>Commingled branch and mainline changes |
| 119 | <tr><td>diff(C6,C5\')<td>diff(C6,C7)<td>Branch changes only |
| 120 | </table></center> |
| 121 | |
| 122 | Remember: C7 and C5\' are bit-for-bit identical. So the output of the |
| 123 | diff is not determined by whether your select C7 or C5\' as the target |
| 124 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 125 | |
| 126 | So to help with the problem of viewing changes associated with a feature |
| 127 | branch, perhaps what is needed is not rebase but rather better tools to |
| 128 | help users identify an appropriate baseline for their diffs. |
| 129 | |
| 130 | ## 3.0 Rebase encourages siloed development |
| 131 | |
| 132 | The [golden rule of rebase][golden] is that you should never do it |
| 133 | on public branches. So if you are using rebase as intended, that means |
| 134 | you are keeping private branches. Or, to put it another way, you are |
| 135 | doing siloed development. You are not sharing your intermediate work |
| 136 | with collaborators. This is not good for product quality. |
| 137 | |
| 138 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| @@ -224,11 +224,11 @@ | |
| 224 | on the first draft. |
| 225 | |
| 226 | Unfortunately, Git does not provide the ability to add corrections |
| 227 | or clarifications to historical check-ins in its blockchain. Hence, |
| 228 | once again, rebase can be seen as an attempt to work around limitations |
| 229 | of Git. Wouldn't it be better to fix the tool rather that to lie about |
| 230 | the project history? |
| 231 | |
| 232 | ## 7.0 Cherry-pick merges work better then rebase |
| 233 | |
| 234 | Perhaps there some cases where a rebase-like transformation |
| @@ -247,11 +247,11 @@ | |
| 247 | cause problems for collaborators if you do them on public branches. |
| 248 | |
| 249 | 4. Cherry-picks preserve both the original and the revised check-ins, |
| 250 | so both timestamps are preserved. |
| 251 | |
| 252 | ## 8.0 Summary And Conclusion |
| 253 | |
| 254 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 255 | omits historical information. It causes problems for collaboration. |
| 256 | And it has no offsetting benefits. |
| 257 | |
| 258 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -104,11 +104,11 @@ | |
| 104 | |
| 105 | The argument from rebase advocates |
| 106 | is that with merge it is difficult to see only the changes associated |
| 107 | with the feature branch without the commingled mainline changes. |
| 108 | In other words, diff(C2,C7) shows changes associated both the feature |
| 109 | branch and from the mainline, whereas in the rebase case |
| 110 | diff(C6,C5\') should only the feature branch changes. |
| 111 | |
| 112 | But that argument is comparing apples to oranges, since the two diffs |
| 113 | do not have the same baseline. The correct way to see only the feature |
| 114 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| @@ -117,22 +117,22 @@ | |
| 117 | <tr><th>Rebase<th>Merge<th>What You See |
| 118 | <tr><td>diff(C2,C5\')<td>diff(C2,C7)<td>Commingled branch and mainline changes |
| 119 | <tr><td>diff(C6,C5\')<td>diff(C6,C7)<td>Branch changes only |
| 120 | </table></center> |
| 121 | |
| 122 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 123 | diff is not determined by whether you select C7 or C5\' as the target |
| 124 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 125 | |
| 126 | So, to help with the problem of viewing changes associated with a feature |
| 127 | branch, perhaps what is needed is not rebase but rather better tools to |
| 128 | help users identify an appropriate baseline for their diffs. |
| 129 | |
| 130 | ## 3.0 Rebase encourages siloed development |
| 131 | |
| 132 | The [golden rule of rebase][golden] is that you should never do it |
| 133 | on public branches, so if you are using rebase as intended, that means |
| 134 | you are keeping private branches. Or, to put it another way, you are |
| 135 | doing siloed development. You are not sharing your intermediate work |
| 136 | with collaborators. This is not good for product quality. |
| 137 | |
| 138 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| @@ -224,11 +224,11 @@ | |
| 224 | on the first draft. |
| 225 | |
| 226 | Unfortunately, Git does not provide the ability to add corrections |
| 227 | or clarifications to historical check-ins in its blockchain. Hence, |
| 228 | once again, rebase can be seen as an attempt to work around limitations |
| 229 | of Git. Wouldn't it be better to fix the tool rather than to lie about |
| 230 | the project history? |
| 231 | |
| 232 | ## 7.0 Cherry-pick merges work better then rebase |
| 233 | |
| 234 | Perhaps there some cases where a rebase-like transformation |
| @@ -247,11 +247,11 @@ | |
| 247 | cause problems for collaborators if you do them on public branches. |
| 248 | |
| 249 | 4. Cherry-picks preserve both the original and the revised check-ins, |
| 250 | so both timestamps are preserved. |
| 251 | |
| 252 | ## 8.0 Summary and conclusion |
| 253 | |
| 254 | Rebasing is an anti-pattern. It is dishonest. It deliberately |
| 255 | omits historical information. It causes problems for collaboration. |
| 256 | And it has no offsetting benefits. |
| 257 | |
| 258 |