Fossil SCM
Rewrote a paragraph in sec.7.2 of the rebaseharm doc for clarity.
Commit
b16db9d6e960fcf6a6dc61fe7ffee19c19538d57b6c01dfcb5c9694abc176b4a
Parent
2cfd12564010011…
1 file changed
+4
-4
+4
-4
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -317,14 +317,14 @@ | ||
| 317 | 317 | that blames the merged check-in as the source of the problem they’re |
| 318 | 318 | chasing down; they then have to manually work out which of the 10 steps |
| 319 | 319 | the original developer took to create it to find the source of the |
| 320 | 320 | actual problem. |
| 321 | 321 | |
| 322 | -Fossil pushes all 11 check-ins to the parent repository by default, so | |
| 323 | -that someone doing that bisect sees the complete check-in history, so | |
| 324 | -the bisect will point them at the single original check-in that caused | |
| 325 | -the problem. | |
| 322 | +An equivalent push in Fossil will send all 11 check-ins to the parent | |
| 323 | +repository so that a later investigator doing the same sort of bisect | |
| 324 | +sees the complete check-in history. That bisect will point the | |
| 325 | +investigator at the single original check-in that caused the problem. | |
| 326 | 326 | |
| 327 | 327 | ### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments |
| 328 | 328 | |
| 329 | 329 | The more comments you have from a given developer on a given body of |
| 330 | 330 | code, the more concise documentation you have of that developer's |
| 331 | 331 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -317,14 +317,14 @@ | |
| 317 | that blames the merged check-in as the source of the problem they’re |
| 318 | chasing down; they then have to manually work out which of the 10 steps |
| 319 | the original developer took to create it to find the source of the |
| 320 | actual problem. |
| 321 | |
| 322 | Fossil pushes all 11 check-ins to the parent repository by default, so |
| 323 | that someone doing that bisect sees the complete check-in history, so |
| 324 | the bisect will point them at the single original check-in that caused |
| 325 | the problem. |
| 326 | |
| 327 | ### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments |
| 328 | |
| 329 | The more comments you have from a given developer on a given body of |
| 330 | code, the more concise documentation you have of that developer's |
| 331 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -317,14 +317,14 @@ | |
| 317 | that blames the merged check-in as the source of the problem they’re |
| 318 | chasing down; they then have to manually work out which of the 10 steps |
| 319 | the original developer took to create it to find the source of the |
| 320 | actual problem. |
| 321 | |
| 322 | An equivalent push in Fossil will send all 11 check-ins to the parent |
| 323 | repository so that a later investigator doing the same sort of bisect |
| 324 | sees the complete check-in history. That bisect will point the |
| 325 | investigator at the single original check-in that caused the problem. |
| 326 | |
| 327 | ### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments |
| 328 | |
| 329 | The more comments you have from a given developer on a given body of |
| 330 | code, the more concise documentation you have of that developer's |
| 331 |