Fossil SCM
Centered the Pikchrs in the rebaseharm doc, and replaced an HTML table with the MD equivalent.
Commit
9607f5b4e4d2db82e6477f78d8c4bff36adc70604870b02a77c3f1ec3a3bb03b
Parent
fc2965be401ed5c…
1 file changed
+14
-12
+14
-12
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -30,11 +30,11 @@ | ||
| 30 | 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | 31 | To help illustrate this fact, |
| 32 | 32 | consider the first rebase example from the |
| 33 | 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | 34 | |
| 35 | -~~~ pikchr toggle | |
| 35 | +~~~ pikchr toggle center | |
| 36 | 36 | scale = 0.8 |
| 37 | 37 | circle "C0" fit |
| 38 | 38 | arrow right 50% |
| 39 | 39 | circle same "C1" |
| 40 | 40 | arrow same |
| @@ -48,11 +48,11 @@ | ||
| 48 | 48 | arrow from C4 to C5 chop |
| 49 | 49 | ~~~ |
| 50 | 50 | |
| 51 | 51 | And the rebase looks like this: |
| 52 | 52 | |
| 53 | -~~~ pikchr toggle | |
| 53 | +~~~ pikchr toggle center | |
| 54 | 54 | scale = 0.8 |
| 55 | 55 | circle "C0" fit |
| 56 | 56 | arrow right 50% |
| 57 | 57 | circle same "C1" |
| 58 | 58 | arrow same |
| @@ -95,11 +95,11 @@ | ||
| 95 | 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | 96 | allows one to see just the changes in the feature branch without |
| 97 | 97 | the concurrent changes in the main line of development. |
| 98 | 98 | Consider a hypothetical case: |
| 99 | 99 | |
| 100 | -~~~ pikchr toggle | |
| 100 | +~~~ pikchr toggle center | |
| 101 | 101 | scale = 0.8 |
| 102 | 102 | circle "C0" fit fill white |
| 103 | 103 | arrow right 50% |
| 104 | 104 | circle same "C1" |
| 105 | 105 | arrow same |
| @@ -123,11 +123,11 @@ | ||
| 123 | 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | 125 | of main in order to remove main-line development differences from |
| 126 | 126 | the feature branch's history: |
| 127 | 127 | |
| 128 | -~~~ pikchr toggle | |
| 128 | +~~~ pikchr toggle center | |
| 129 | 129 | # Duplicated below in section 5.0 |
| 130 | 130 | scale = 0.8 |
| 131 | 131 | circle "C0" fit fill white |
| 132 | 132 | arrow right 50% |
| 133 | 133 | circle same "C1" |
| @@ -158,11 +158,11 @@ | ||
| 158 | 158 | [separately](#collapsing). |
| 159 | 159 | |
| 160 | 160 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 161 | 161 | history is the following merge: |
| 162 | 162 | |
| 163 | -~~~ pikchr toggle | |
| 163 | +~~~ pikchr toggle center | |
| 164 | 164 | scale = 0.8 |
| 165 | 165 | circle "C0" fit fill white |
| 166 | 166 | arrow right 50% |
| 167 | 167 | circle same "C1" |
| 168 | 168 | arrow same |
| @@ -198,16 +198,18 @@ | ||
| 198 | 198 | |
| 199 | 199 | But that argument is comparing apples to oranges, since the two diffs |
| 200 | 200 | do not have the same baseline. The correct way to see only the feature |
| 201 | 201 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| 202 | 202 | |
| 203 | -<table border="1" cellpadding="5" cellspacing="0" | |
| 204 | - style="margin-left:auto; margin-right:auto"> | |
| 205 | -<tr><th>Rebase<th>Merge<th>What You See | |
| 206 | -<tr><td>diff(C2,C5\')<td>diff(C2,C7)<td>Commingled branch and mainline changes | |
| 207 | -<tr><td>diff(C6,C5\')<td>diff(C6,C7)<td>Branch changes only | |
| 208 | -</table> | |
| 203 | +<div align=center> | |
| 204 | + | |
| 205 | +| Rebase | Merge | What You See | | |
| 206 | +|---------------|-------------|----------------------------------------| | |
| 207 | +| diff(C2,C5\') | diff(C2,C7) | Commingled branch and mainline changes | | |
| 208 | +| diff(C6,C5\') | diff(C6,C7) | Branch changes only | | |
| 209 | + | |
| 210 | +</div> | |
| 209 | 211 | |
| 210 | 212 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 211 | 213 | diff is not determined by whether you select C7 or C5\' as the target |
| 212 | 214 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 213 | 215 | |
| @@ -256,11 +258,11 @@ | ||
| 256 | 258 | |
| 257 | 259 | ## <a id="timestamps"></a>4.0 Rebase causes timestamp confusion |
| 258 | 260 | |
| 259 | 261 | Consider the earlier example of rebasing a feature branch: |
| 260 | 262 | |
| 261 | -~~~ pikchr toggle | |
| 263 | +~~~ pikchr toggle center | |
| 262 | 264 | # Copy of second diagram in section 2.2 above |
| 263 | 265 | scale = 0.8 |
| 264 | 266 | circle "C0" fit fill white |
| 265 | 267 | arrow right 50% |
| 266 | 268 | circle same "C1" |
| 267 | 269 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -30,11 +30,11 @@ | |
| 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 |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 | ~~~ pikchr toggle |
| 36 | scale = 0.8 |
| 37 | circle "C0" fit |
| 38 | arrow right 50% |
| 39 | circle same "C1" |
| 40 | arrow same |
| @@ -48,11 +48,11 @@ | |
| 48 | arrow from C4 to C5 chop |
| 49 | ~~~ |
| 50 | |
| 51 | And the rebase looks like this: |
| 52 | |
| 53 | ~~~ pikchr toggle |
| 54 | scale = 0.8 |
| 55 | circle "C0" fit |
| 56 | arrow right 50% |
| 57 | circle same "C1" |
| 58 | arrow same |
| @@ -95,11 +95,11 @@ | |
| 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | allows one to see just the changes in the feature branch without |
| 97 | the concurrent changes in the main line of development. |
| 98 | Consider a hypothetical case: |
| 99 | |
| 100 | ~~~ pikchr toggle |
| 101 | scale = 0.8 |
| 102 | circle "C0" fit fill white |
| 103 | arrow right 50% |
| 104 | circle same "C1" |
| 105 | arrow same |
| @@ -123,11 +123,11 @@ | |
| 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | of main in order to remove main-line development differences from |
| 126 | the feature branch's history: |
| 127 | |
| 128 | ~~~ pikchr toggle |
| 129 | # Duplicated below in section 5.0 |
| 130 | scale = 0.8 |
| 131 | circle "C0" fit fill white |
| 132 | arrow right 50% |
| 133 | circle same "C1" |
| @@ -158,11 +158,11 @@ | |
| 158 | [separately](#collapsing). |
| 159 | |
| 160 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 161 | history is the following merge: |
| 162 | |
| 163 | ~~~ pikchr toggle |
| 164 | scale = 0.8 |
| 165 | circle "C0" fit fill white |
| 166 | arrow right 50% |
| 167 | circle same "C1" |
| 168 | arrow same |
| @@ -198,16 +198,18 @@ | |
| 198 | |
| 199 | But that argument is comparing apples to oranges, since the two diffs |
| 200 | do not have the same baseline. The correct way to see only the feature |
| 201 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| 202 | |
| 203 | <table border="1" cellpadding="5" cellspacing="0" |
| 204 | style="margin-left:auto; margin-right:auto"> |
| 205 | <tr><th>Rebase<th>Merge<th>What You See |
| 206 | <tr><td>diff(C2,C5\')<td>diff(C2,C7)<td>Commingled branch and mainline changes |
| 207 | <tr><td>diff(C6,C5\')<td>diff(C6,C7)<td>Branch changes only |
| 208 | </table> |
| 209 | |
| 210 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 211 | diff is not determined by whether you select C7 or C5\' as the target |
| 212 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 213 | |
| @@ -256,11 +258,11 @@ | |
| 256 | |
| 257 | ## <a id="timestamps"></a>4.0 Rebase causes timestamp confusion |
| 258 | |
| 259 | Consider the earlier example of rebasing a feature branch: |
| 260 | |
| 261 | ~~~ pikchr toggle |
| 262 | # Copy of second diagram in section 2.2 above |
| 263 | scale = 0.8 |
| 264 | circle "C0" fit fill white |
| 265 | arrow right 50% |
| 266 | circle same "C1" |
| 267 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -30,11 +30,11 @@ | |
| 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 |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 | ~~~ pikchr toggle center |
| 36 | scale = 0.8 |
| 37 | circle "C0" fit |
| 38 | arrow right 50% |
| 39 | circle same "C1" |
| 40 | arrow same |
| @@ -48,11 +48,11 @@ | |
| 48 | arrow from C4 to C5 chop |
| 49 | ~~~ |
| 50 | |
| 51 | And the rebase looks like this: |
| 52 | |
| 53 | ~~~ pikchr toggle center |
| 54 | scale = 0.8 |
| 55 | circle "C0" fit |
| 56 | arrow right 50% |
| 57 | circle same "C1" |
| 58 | arrow same |
| @@ -95,11 +95,11 @@ | |
| 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | allows one to see just the changes in the feature branch without |
| 97 | the concurrent changes in the main line of development. |
| 98 | Consider a hypothetical case: |
| 99 | |
| 100 | ~~~ pikchr toggle center |
| 101 | scale = 0.8 |
| 102 | circle "C0" fit fill white |
| 103 | arrow right 50% |
| 104 | circle same "C1" |
| 105 | arrow same |
| @@ -123,11 +123,11 @@ | |
| 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | of main in order to remove main-line development differences from |
| 126 | the feature branch's history: |
| 127 | |
| 128 | ~~~ pikchr toggle center |
| 129 | # Duplicated below in section 5.0 |
| 130 | scale = 0.8 |
| 131 | circle "C0" fit fill white |
| 132 | arrow right 50% |
| 133 | circle same "C1" |
| @@ -158,11 +158,11 @@ | |
| 158 | [separately](#collapsing). |
| 159 | |
| 160 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 161 | history is the following merge: |
| 162 | |
| 163 | ~~~ pikchr toggle center |
| 164 | scale = 0.8 |
| 165 | circle "C0" fit fill white |
| 166 | arrow right 50% |
| 167 | circle same "C1" |
| 168 | arrow same |
| @@ -198,16 +198,18 @@ | |
| 198 | |
| 199 | But that argument is comparing apples to oranges, since the two diffs |
| 200 | do not have the same baseline. The correct way to see only the feature |
| 201 | branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). |
| 202 | |
| 203 | <div align=center> |
| 204 | |
| 205 | | Rebase | Merge | What You See | |
| 206 | |---------------|-------------|----------------------------------------| |
| 207 | | diff(C2,C5\') | diff(C2,C7) | Commingled branch and mainline changes | |
| 208 | | diff(C6,C5\') | diff(C6,C7) | Branch changes only | |
| 209 | |
| 210 | </div> |
| 211 | |
| 212 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 213 | diff is not determined by whether you select C7 or C5\' as the target |
| 214 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 215 | |
| @@ -256,11 +258,11 @@ | |
| 258 | |
| 259 | ## <a id="timestamps"></a>4.0 Rebase causes timestamp confusion |
| 260 | |
| 261 | Consider the earlier example of rebasing a feature branch: |
| 262 | |
| 263 | ~~~ pikchr toggle center |
| 264 | # Copy of second diagram in section 2.2 above |
| 265 | scale = 0.8 |
| 266 | circle "C0" fit fill white |
| 267 | arrow right 50% |
| 268 | circle same "C1" |
| 269 |