Fossil SCM
Put 7.x series headlines one level deeper so they nest properly under their parent, the 7.0 section, in rebaseharm.md doc.
Commit
5453dbff5bd03a49d95d6f5527f678c59fbb3e5e167386fa53d6683c103204c3
Parent
d357f81b6c17931…
1 file changed
+5
-5
+5
-5
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -238,11 +238,11 @@ | ||
| 238 | 238 | |
| 239 | 239 | The common counterargument is that collapsed check-ins represent a |
| 240 | 240 | better world, the ideal we’re striving for. What that argument overlooks |
| 241 | 241 | is that we must throw away valuable information to get there. |
| 242 | 242 | |
| 243 | -## <a name="empathy"></a>7.1 Individual check-ins support developer empathy | |
| 243 | +### <a name="empathy"></a>7.1 Individual check-ins support developer empathy | |
| 244 | 244 | |
| 245 | 245 | Ideally, future developers of our software can understand every feature |
| 246 | 246 | in it using only context available in the version of the code they start |
| 247 | 247 | work with. Prior to widespread version control, developers had no choice |
| 248 | 248 | but to work that way. Pre-existing codebases could only be understood |
| @@ -283,11 +283,11 @@ | ||
| 283 | 283 | that collapses a whole branch’s worth of changes down to a single |
| 284 | 284 | finished feature. |
| 285 | 285 | |
| 286 | 286 | [sdm]: ./fossil-v-git.wiki#durable |
| 287 | 287 | |
| 288 | -## <a name="bisecting"></a>7.2 Bisecting works better on small check-ins | |
| 288 | +### <a name="bisecting"></a>7.2 Bisecting works better on small check-ins | |
| 289 | 289 | |
| 290 | 290 | Git lets a developer write a feature in ten check-ins but collapse it |
| 291 | 291 | down to an eleventh check-in and then deliberately push only that final |
| 292 | 292 | collapsed check-in to the parent repo. Someone else may then do a bisect |
| 293 | 293 | that blames the merged check-in as the source of the problem they’re |
| @@ -298,11 +298,11 @@ | ||
| 298 | 298 | Fossil pushes all 11 check-ins to the parent repository by default, so |
| 299 | 299 | that someone doing that bisect sees the complete check-in history, so |
| 300 | 300 | the bisect will point them at the single original check-in that caused |
| 301 | 301 | the problem. |
| 302 | 302 | |
| 303 | -## <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments | |
| 303 | +### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments | |
| 304 | 304 | |
| 305 | 305 | The more comments you have from a given developer on a given body of |
| 306 | 306 | code, the more concise documentation you have of that developer’s |
| 307 | 307 | thought process. To resume the bisecting example, a developer trying to |
| 308 | 308 | work out what the original developer was thinking with a given change |
| @@ -310,11 +310,11 @@ | ||
| 310 | 310 | one check-in out of ten blamed by the “bisect” command was trying to |
| 311 | 311 | accomplish than if they must work that out from the eleventh check-in’s |
| 312 | 312 | comment, which only explains the “clean” version of the collapsed |
| 313 | 313 | feature. |
| 314 | 314 | |
| 315 | -## <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins | |
| 315 | +### <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins | |
| 316 | 316 | |
| 317 | 317 | While working on a new feature in one branch, you may come across a bug |
| 318 | 318 | in the pre-existing code that you need to fix in order for work on that |
| 319 | 319 | feature to proceed. You could choose to switch briefly back to the |
| 320 | 320 | parent branch, develop the fix there, check it in, then merge the parent |
| @@ -352,11 +352,11 @@ | ||
| 352 | 352 | branch. Even if they manage to do their work without error, it takes |
| 353 | 353 | them more time to do the cherry-pick that way. |
| 354 | 354 | |
| 355 | 355 | [rh]: https://en.wikipedia.org/wiki/Red_Hat |
| 356 | 356 | |
| 357 | -## <a name="backouts"></a>7.5 Back-outs also work better with small check-ins | |
| 357 | +### <a name="backouts"></a>7.5 Back-outs also work better with small check-ins | |
| 358 | 358 | |
| 359 | 359 | The inverse of the cherry-pick merge is the back-out merge. If you push |
| 360 | 360 | only a collapsed version of a private working branch up to the parent |
| 361 | 361 | repo, those working from that parent repo cannot automatically back out |
| 362 | 362 | any of the individual check-ins that went into that private branch. |
| 363 | 363 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -238,11 +238,11 @@ | |
| 238 | |
| 239 | The common counterargument is that collapsed check-ins represent a |
| 240 | better world, the ideal we’re striving for. What that argument overlooks |
| 241 | is that we must throw away valuable information to get there. |
| 242 | |
| 243 | ## <a name="empathy"></a>7.1 Individual check-ins support developer empathy |
| 244 | |
| 245 | Ideally, future developers of our software can understand every feature |
| 246 | in it using only context available in the version of the code they start |
| 247 | work with. Prior to widespread version control, developers had no choice |
| 248 | but to work that way. Pre-existing codebases could only be understood |
| @@ -283,11 +283,11 @@ | |
| 283 | that collapses a whole branch’s worth of changes down to a single |
| 284 | finished feature. |
| 285 | |
| 286 | [sdm]: ./fossil-v-git.wiki#durable |
| 287 | |
| 288 | ## <a name="bisecting"></a>7.2 Bisecting works better on small check-ins |
| 289 | |
| 290 | Git lets a developer write a feature in ten check-ins but collapse it |
| 291 | down to an eleventh check-in and then deliberately push only that final |
| 292 | collapsed check-in to the parent repo. Someone else may then do a bisect |
| 293 | that blames the merged check-in as the source of the problem they’re |
| @@ -298,11 +298,11 @@ | |
| 298 | Fossil pushes all 11 check-ins to the parent repository by default, so |
| 299 | that someone doing that bisect sees the complete check-in history, so |
| 300 | the bisect will point them at the single original check-in that caused |
| 301 | the problem. |
| 302 | |
| 303 | ## <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments |
| 304 | |
| 305 | The more comments you have from a given developer on a given body of |
| 306 | code, the more concise documentation you have of that developer’s |
| 307 | thought process. To resume the bisecting example, a developer trying to |
| 308 | work out what the original developer was thinking with a given change |
| @@ -310,11 +310,11 @@ | |
| 310 | one check-in out of ten blamed by the “bisect” command was trying to |
| 311 | accomplish than if they must work that out from the eleventh check-in’s |
| 312 | comment, which only explains the “clean” version of the collapsed |
| 313 | feature. |
| 314 | |
| 315 | ## <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins |
| 316 | |
| 317 | While working on a new feature in one branch, you may come across a bug |
| 318 | in the pre-existing code that you need to fix in order for work on that |
| 319 | feature to proceed. You could choose to switch briefly back to the |
| 320 | parent branch, develop the fix there, check it in, then merge the parent |
| @@ -352,11 +352,11 @@ | |
| 352 | branch. Even if they manage to do their work without error, it takes |
| 353 | them more time to do the cherry-pick that way. |
| 354 | |
| 355 | [rh]: https://en.wikipedia.org/wiki/Red_Hat |
| 356 | |
| 357 | ## <a name="backouts"></a>7.5 Back-outs also work better with small check-ins |
| 358 | |
| 359 | The inverse of the cherry-pick merge is the back-out merge. If you push |
| 360 | only a collapsed version of a private working branch up to the parent |
| 361 | repo, those working from that parent repo cannot automatically back out |
| 362 | any of the individual check-ins that went into that private branch. |
| 363 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -238,11 +238,11 @@ | |
| 238 | |
| 239 | The common counterargument is that collapsed check-ins represent a |
| 240 | better world, the ideal we’re striving for. What that argument overlooks |
| 241 | is that we must throw away valuable information to get there. |
| 242 | |
| 243 | ### <a name="empathy"></a>7.1 Individual check-ins support developer empathy |
| 244 | |
| 245 | Ideally, future developers of our software can understand every feature |
| 246 | in it using only context available in the version of the code they start |
| 247 | work with. Prior to widespread version control, developers had no choice |
| 248 | but to work that way. Pre-existing codebases could only be understood |
| @@ -283,11 +283,11 @@ | |
| 283 | that collapses a whole branch’s worth of changes down to a single |
| 284 | finished feature. |
| 285 | |
| 286 | [sdm]: ./fossil-v-git.wiki#durable |
| 287 | |
| 288 | ### <a name="bisecting"></a>7.2 Bisecting works better on small check-ins |
| 289 | |
| 290 | Git lets a developer write a feature in ten check-ins but collapse it |
| 291 | down to an eleventh check-in and then deliberately push only that final |
| 292 | collapsed check-in to the parent repo. Someone else may then do a bisect |
| 293 | that blames the merged check-in as the source of the problem they’re |
| @@ -298,11 +298,11 @@ | |
| 298 | Fossil pushes all 11 check-ins to the parent repository by default, so |
| 299 | that someone doing that bisect sees the complete check-in history, so |
| 300 | the bisect will point them at the single original check-in that caused |
| 301 | the problem. |
| 302 | |
| 303 | ### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments |
| 304 | |
| 305 | The more comments you have from a given developer on a given body of |
| 306 | code, the more concise documentation you have of that developer’s |
| 307 | thought process. To resume the bisecting example, a developer trying to |
| 308 | work out what the original developer was thinking with a given change |
| @@ -310,11 +310,11 @@ | |
| 310 | one check-in out of ten blamed by the “bisect” command was trying to |
| 311 | accomplish than if they must work that out from the eleventh check-in’s |
| 312 | comment, which only explains the “clean” version of the collapsed |
| 313 | feature. |
| 314 | |
| 315 | ### <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins |
| 316 | |
| 317 | While working on a new feature in one branch, you may come across a bug |
| 318 | in the pre-existing code that you need to fix in order for work on that |
| 319 | feature to proceed. You could choose to switch briefly back to the |
| 320 | parent branch, develop the fix there, check it in, then merge the parent |
| @@ -352,11 +352,11 @@ | |
| 352 | branch. Even if they manage to do their work without error, it takes |
| 353 | them more time to do the cherry-pick that way. |
| 354 | |
| 355 | [rh]: https://en.wikipedia.org/wiki/Red_Hat |
| 356 | |
| 357 | ### <a name="backouts"></a>7.5 Back-outs also work better with small check-ins |
| 358 | |
| 359 | The inverse of the cherry-pick merge is the back-out merge. If you push |
| 360 | only a collapsed version of a private working branch up to the parent |
| 361 | repo, those working from that parent repo cannot automatically back out |
| 362 | any of the individual check-ins that went into that private branch. |
| 363 |