Fossil SCM
Still more editorial changes to rebaseharm.md.
Commit
9b068a39799f83afac4dc520b8364216738b4d106ab17cc7edee6529da84fff0
Parent
d0807c23ead6517…
1 file changed
+17
-11
+17
-11
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -57,10 +57,13 @@ | ||
| 57 | 57 | important. |
| 58 | 58 | |
| 59 | 59 | So, another way of thinking about rebase is that it is a kind of |
| 60 | 60 | merge that intentionally forgets some details in order to |
| 61 | 61 | not overwhelm the weak history display mechanisms available in Git. |
| 62 | +Wouldn't it be better, less error-prone, and easier on users, | |
| 63 | +to enhance the history display mechanisms in Git so that rebasing | |
| 64 | +for a clean, linear history became unnecessary? | |
| 62 | 65 | |
| 63 | 66 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 64 | 67 | |
| 65 | 68 | Another argument, often cited, is that rebasing a feature branch |
| 66 | 69 | allows one to see just the changes in the feature branch without |
| @@ -147,11 +150,11 @@ | ||
| 147 | 150 | |
| 148 | 151 | Given that, is it better for those many eyeballs to find your problems |
| 149 | 152 | while they're still isolated on a feature branch, or should that vetting |
| 150 | 153 | wait until you finally push a collapsed version of a private working |
| 151 | 154 | branch to the parent repo? Will the many eyeballs even see those errors |
| 152 | -when they’re intermingled with code implementing some tasty new feature? | |
| 155 | +when they’re intermingled with code implementing some compelling new feature? | |
| 153 | 156 | |
| 154 | 157 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 155 | 158 | |
| 156 | 159 | Rebase adds new check-ins to the blockchain without giving the operator |
| 157 | 160 | an opportunity to test and verify those check-ins. Just because the |
| @@ -207,25 +210,25 @@ | ||
| 207 | 210 | |
| 208 | 211 | In fairness to the Git documentation authors, changing the |
| 209 | 212 | project history appears to be the only way to make editorial |
| 210 | 213 | changes in Git. |
| 211 | 214 | But it does not have to be that way. |
| 212 | -Fossil supports improvements to "the story of how your project | |
| 213 | -was made" without changing the actual history of your project | |
| 215 | +Fossil demonstrations how "the story of your project" | |
| 216 | +can be enhanced without changing the actual history | |
| 214 | 217 | by allowing users to: |
| 215 | 218 | |
| 216 | - 1. Edit check-in comments to fix typos or enhance clarify | |
| 217 | - 2. Attaching supplemental notes to check-ins or whole branches | |
| 218 | - 3. Cross-referencing check-ins with each other, or with | |
| 219 | + 1. Edit check-in comments to fix typos or enhance clarity | |
| 220 | + 2. Attach supplemental notes to check-ins or whole branches | |
| 221 | + 3. Cross-reference check-ins with each other, or with | |
| 219 | 222 | wiki, tickets, forum posts, and/or embedded documentation |
| 220 | 223 | 4. Cause mistaken or unused branches to be hidden from |
| 221 | 224 | routine display |
| 222 | 225 | 5. Fix faulty check-in date/times resulting from misconfigured |
| 223 | 226 | system clocks |
| 224 | 227 | 6. And so forth.... |
| 225 | 228 | |
| 226 | -These changes are accomplishes not by removing or modifying existing | |
| 229 | +These changes are accomplished not by removing or modifying existing | |
| 227 | 230 | repository entries, but rather by adding new supplemental records. |
| 228 | 231 | The original incorrect or unclear inputs are preserved and are |
| 229 | 232 | readily accessible. The original history is preserved. |
| 230 | 233 | But for routine display purposes, the more |
| 231 | 234 | readable edited presentation is provided. |
| @@ -233,15 +236,18 @@ | ||
| 233 | 236 | A repository can be a true and accurate |
| 234 | 237 | representation of history even without getting everything perfect |
| 235 | 238 | on the first draft. Those are not contradictory goals, at least |
| 236 | 239 | not in theory. |
| 237 | 240 | |
| 238 | -Unfortunately, Git does not provide the ability to add corrections | |
| 239 | -or clarifications to historical check-ins. Hence, once again, | |
| 241 | +Unfortunately, Git does not currently provide the ability to add | |
| 242 | +corrections or clarifications or supplimental notes to historical check-ins. | |
| 243 | +Hence, once again, | |
| 240 | 244 | rebase can be seen as an attempt to work around limitations |
| 241 | -of Git. Wouldn't it be better to fix the tool rather than | |
| 242 | -fabricate a fictitious project history? | |
| 245 | +of Git. Git could be enhanced to support editorial changes | |
| 246 | +to check-ins. | |
| 247 | +Wouldn't it be better to fix the version control tool | |
| 248 | +rather than requiring users to fabricate a fictitious project history? | |
| 243 | 249 | |
| 244 | 250 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 245 | 251 | |
| 246 | 252 | One of the oft-cited advantages of rebasing in Git is that it lets you |
| 247 | 253 | collapse multiple check-ins down to a single check-in to make the |
| 248 | 254 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -57,10 +57,13 @@ | |
| 57 | important. |
| 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 |
| @@ -147,11 +150,11 @@ | |
| 147 | |
| 148 | Given that, is it better for those many eyeballs to find your problems |
| 149 | while they're still isolated on a feature branch, or should that vetting |
| 150 | wait until you finally push a collapsed version of a private working |
| 151 | branch to the parent repo? Will the many eyeballs even see those errors |
| 152 | when they’re intermingled with code implementing some tasty new feature? |
| 153 | |
| 154 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 155 | |
| 156 | Rebase adds new check-ins to the blockchain without giving the operator |
| 157 | an opportunity to test and verify those check-ins. Just because the |
| @@ -207,25 +210,25 @@ | |
| 207 | |
| 208 | In fairness to the Git documentation authors, changing the |
| 209 | project history appears to be the only way to make editorial |
| 210 | changes in Git. |
| 211 | But it does not have to be that way. |
| 212 | Fossil supports improvements to "the story of how your project |
| 213 | was made" without changing the actual history of your project |
| 214 | by allowing users to: |
| 215 | |
| 216 | 1. Edit check-in comments to fix typos or enhance clarify |
| 217 | 2. Attaching supplemental notes to check-ins or whole branches |
| 218 | 3. Cross-referencing check-ins with each other, or with |
| 219 | wiki, tickets, forum posts, and/or embedded documentation |
| 220 | 4. Cause mistaken or unused branches to be hidden from |
| 221 | routine display |
| 222 | 5. Fix faulty check-in date/times resulting from misconfigured |
| 223 | system clocks |
| 224 | 6. And so forth.... |
| 225 | |
| 226 | These changes are accomplishes not by removing or modifying existing |
| 227 | repository entries, but rather by adding new supplemental records. |
| 228 | The original incorrect or unclear inputs are preserved and are |
| 229 | readily accessible. The original history is preserved. |
| 230 | But for routine display purposes, the more |
| 231 | readable edited presentation is provided. |
| @@ -233,15 +236,18 @@ | |
| 233 | A repository can be a true and accurate |
| 234 | representation of history even without getting everything perfect |
| 235 | on the first draft. Those are not contradictory goals, at least |
| 236 | not in theory. |
| 237 | |
| 238 | Unfortunately, Git does not provide the ability to add corrections |
| 239 | or clarifications to historical check-ins. Hence, once again, |
| 240 | rebase can be seen as an attempt to work around limitations |
| 241 | of Git. Wouldn't it be better to fix the tool rather than |
| 242 | fabricate a fictitious project history? |
| 243 | |
| 244 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 245 | |
| 246 | One of the oft-cited advantages of rebasing in Git is that it lets you |
| 247 | collapse multiple check-ins down to a single check-in to make the |
| 248 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -57,10 +57,13 @@ | |
| 57 | important. |
| 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 | Wouldn't it be better, less error-prone, and easier on users, |
| 63 | to enhance the history display mechanisms in Git so that rebasing |
| 64 | for a clean, linear history became unnecessary? |
| 65 | |
| 66 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 67 | |
| 68 | Another argument, often cited, is that rebasing a feature branch |
| 69 | allows one to see just the changes in the feature branch without |
| @@ -147,11 +150,11 @@ | |
| 150 | |
| 151 | Given that, is it better for those many eyeballs to find your problems |
| 152 | while they're still isolated on a feature branch, or should that vetting |
| 153 | wait until you finally push a collapsed version of a private working |
| 154 | branch to the parent repo? Will the many eyeballs even see those errors |
| 155 | when they’re intermingled with code implementing some compelling new feature? |
| 156 | |
| 157 | ## <a name="testing"></a>4.0 Rebase commits untested check-ins to the blockchain |
| 158 | |
| 159 | Rebase adds new check-ins to the blockchain without giving the operator |
| 160 | an opportunity to test and verify those check-ins. Just because the |
| @@ -207,25 +210,25 @@ | |
| 210 | |
| 211 | In fairness to the Git documentation authors, changing the |
| 212 | project history appears to be the only way to make editorial |
| 213 | changes in Git. |
| 214 | But it does not have to be that way. |
| 215 | Fossil demonstrations how "the story of your project" |
| 216 | can be enhanced without changing the actual history |
| 217 | by allowing users to: |
| 218 | |
| 219 | 1. Edit check-in comments to fix typos or enhance clarity |
| 220 | 2. Attach supplemental notes to check-ins or whole branches |
| 221 | 3. Cross-reference check-ins with each other, or with |
| 222 | wiki, tickets, forum posts, and/or embedded documentation |
| 223 | 4. Cause mistaken or unused branches to be hidden from |
| 224 | routine display |
| 225 | 5. Fix faulty check-in date/times resulting from misconfigured |
| 226 | system clocks |
| 227 | 6. And so forth.... |
| 228 | |
| 229 | These changes are accomplished not by removing or modifying existing |
| 230 | repository entries, but rather by adding new supplemental records. |
| 231 | The original incorrect or unclear inputs are preserved and are |
| 232 | readily accessible. The original history is preserved. |
| 233 | But for routine display purposes, the more |
| 234 | readable edited presentation is provided. |
| @@ -233,15 +236,18 @@ | |
| 236 | A repository can be a true and accurate |
| 237 | representation of history even without getting everything perfect |
| 238 | on the first draft. Those are not contradictory goals, at least |
| 239 | not in theory. |
| 240 | |
| 241 | Unfortunately, Git does not currently provide the ability to add |
| 242 | corrections or clarifications or supplimental notes to historical check-ins. |
| 243 | Hence, once again, |
| 244 | rebase can be seen as an attempt to work around limitations |
| 245 | of Git. Git could be enhanced to support editorial changes |
| 246 | to check-ins. |
| 247 | Wouldn't it be better to fix the version control tool |
| 248 | rather than requiring users to fabricate a fictitious project history? |
| 249 | |
| 250 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 251 | |
| 252 | One of the oft-cited advantages of rebasing in Git is that it lets you |
| 253 | collapse multiple check-ins down to a single check-in to make the |
| 254 |