Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Convert the diagrams in the "Rebase Considered Harmful" document over to Pikchr. |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
38d6a8f30eb0d58a9817350f9d987c04 |
User & Date: | drh 2020-09-19 00:44:46 |
References
2020-09-29
| ||
01:07 | Removed www/rebase??.graphml, being the yEd inputs for generated SVGs replaced with Pikchrs in commit [38d6a8f3]. ... (check-in: f3c3a099 user: wyoung tags: trunk) | |
Context
2020-09-19
| ||
04:09 | Update pikchr.c with support for dist(P1,P2) and copying the layer using "same". ... (check-in: af52ad89 user: drh tags: trunk) | |
00:44 | Convert the diagrams in the "Rebase Considered Harmful" document over to Pikchr. ... (check-in: 38d6a8f3 user: drh tags: trunk) | |
2020-09-18
| ||
22:55 | New pikchr.c with improved estimates for bounding boxes on text. ... (check-in: bac677f7 user: drh tags: trunk) | |
Changes
Deleted www/rebase01.svg.
|
| < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < |
Deleted www/rebase02.svg.
|
| < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < |
Deleted www/rebase03.svg.
|
| < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < |
Deleted www/rebase04.svg.
|
| < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < |
Deleted www/rebase05.svg.
|
| < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < |
Changes to www/rebaseharm.md.
︙ | ︙ | |||
28 29 30 31 32 33 34 | A rebase is really nothing more than a merge (or a series of merges) that deliberately forgets one of the parents of each merge step. To help illustrate this fact, consider the first rebase example from the [Git documentation][gitrebase]. The merge looks like this: | > | > > > > > > > > > > > > > > | > > > > > > > > > > > > | 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 | A rebase is really nothing more than a merge (or a series of merges) that deliberately forgets one of the parents of each merge step. To help illustrate this fact, consider the first rebase example from the [Git documentation][gitrebase]. The merge looks like this: ~~~ pikchr scale = 0.8 circle "C0" fit arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C3" arrow same circle same "C5" circle same "C4" at 1cm above C3 arrow from C2 to C4 chop arrow from C4 to C5 chop ~~~ And the rebase looks like this: ~~~ pikchr scale = 0.8 circle "C0" fit arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C3" arrow same circle same "C4'" circle same "C4" at 1cm above C3 arrow from C2 to C4 chop ~~~ As the [Git documentation][gitrebase] points out, check-ins C4\' and C5 are identical. The only difference between C4\' and C5 is that C5 records the fact that C4 is its merge parent but C4\' does not. Thus, a rebase is just a merge that forgets where it came from. |
︙ | ︙ | |||
66 67 68 69 70 71 72 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs Another argument, often cited, is that rebasing a feature branch allows one to see just the changes in the feature branch without the concurrent changes in the main line of development. Consider a hypothetical case: | > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > | 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs Another argument, often cited, is that rebasing a feature branch allows one to see just the changes in the feature branch without the concurrent changes in the main line of development. Consider a hypothetical case: ~~~ pikchr scale = 0.8 circle "C0" fit fill white arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C4" arrow same circle same "C6" circle same "C3" at last arrow.width + C0.rad*2 heading 30 from C2 arrow right 50% circle same "C5" arrow from C2 to C3 chop box ht C3.y-C2.y wid C6.e.x-C0.w.x+1.5*C1.rad at C2 behind C0 fill 0xc6e2ff color 0xaac5df box ht previous.ht wid previous.wid*0.55 with .se at previous.ne \ behind C0 fill 0x9accfc color 0xaac5df text "feature" with .s at previous.n text "main" with .n at first box.s ~~~ In the above, a feature branch consisting of check-ins C3 and C5 is run concurrently with the main line in check-ins C4 and C6. Advocates for rebase say that you should rebase the feature branch to the tip of main in order to remove main-line development differences from the feature branch's history: ~~~ pikchr scale = 0.8 circle "C0" fit fill white arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C4" arrow same circle same "C6" circle same "C3" at last arrow.width + C0.rad*2 heading 30 from C2 arrow right 50% circle same "C5" arrow from C2 to C3 chop C3P: circle same "C3'" at first arrow.width + C0.rad*2 heading 30 from C6 arrow right 50% from C3P.e C5P: circle same "C5'" arrow from C6 to C3P chop box ht C3.y-C2.y wid C5P.e.x-C0.w.x+1.5*C1.rad with .w at 0.5*(first arrow.wid) west of C0.w \ behind C0 fill 0xc6e2ff color 0xaac5df box ht previous.ht wid previous.e.x - C2.w.x with .se at previous.ne \ behind C0 fill 0x9accfc color 0xaac5df ~~~ You could choose to collapse C3\' and C5\' into a single check-in as part of this rebase, but that's a side issue we'll deal with [separately](#collapsing). Because Fossil purposefully lacks rebase, the closest you can get to this same check-in history is the following merge: ~~~ pikchr scale = 0.8 circle "C0" fit fill white arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C4" arrow same circle same "C6" circle same "C3" at last arrow.width + C0.rad*2 heading 30 from C2 arrow right 50% circle same "C5" arrow same circle same "C7" arrow from C2 to C3 chop arrow from C6 to C7 chop box ht C3.y-C2.y wid C7.e.x-C0.w.x+1.5*C1.rad with .w at 0.5*(first arrow.wid) west of C0.w \ behind C0 fill 0xc6e2ff color 0xaac5df box ht previous.ht wid previous.e.x - C2.w.x with .se at previous.ne \ behind C0 fill 0x9accfc color 0xaac5df ~~~ Check-ins C5\' and C7 check-ins hold identical code. The only difference is in their history. The argument from rebase advocates is that with merge it is difficult to see only the changes associated with the feature branch without the commingled mainline changes. |
︙ | ︙ |