Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch extract-pikchr Excluding Merge-Ins
This is equivalent to a diff from 1ddb4008 to a9dcda5d
2020-10-12
| ||
13:39 | New document: pikchr.md ... (check-in: a92365d7 user: drh tags: trunk) | |
2020-10-11
| ||
07:03 |
Attempt to use the feature added in [e32214a409] to extract the
duplicate Pikchr code for diagram #4 in the rebase doc as a separate
file, so we can refer to it twice via a Markdown image link instead.
Doesn't work, but my next steps require a checkin I can reference.
EDIT: Per forum feedback (https://fossil-scm.org/forum/forumpost/5c177b55b6) I'm abandoning this. ... (Closed-Leaf check-in: a9dcda5d user: wyoung tags: extract-pikchr) | |
06:51 | Greatly expanded the simple definition of "blockchain" in the eponymous doc to include more details of common blockchain implementations to draw clearer parallels. This causes our conclusion to flip around from the prior version of this doc, but it's worth keeping the doc because it serves to compare and contrast Fossil to other systems. ... (check-in: 1ddb4008 user: wyoung tags: trunk) | |
01:19 | Understand files ending in ".pikchr" to be Pikchr source text and render them appropriately. ... (check-in: e32214a4 user: drh tags: trunk) | |
2020-10-08
| ||
08:48 | Drew better analogies between Bitcoin's answer to the 51% attack and to GitHub in the new Anonymity section of the blockchain doc to show that Fossil doesn't even try to provide the sorts of behavior that allow fully anonymous contribution to a blockchain. ... (Closed-Leaf check-in: 87b1385d user: wyoung tags: fossil-as-blockchain) | |
Added www/rebase04.pikchr.
|
Changes to www/rebaseharm.md.
︙ | |||
121 122 123 124 125 126 127 | 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 | - - - + - - - - - - - - - - - - - - - - - - - - - - + | 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: |
︙ | |||
253 254 255 256 257 258 259 | 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 | - - - - - - - - - - - - - - - - - - - - - + - - - - - | branch to the parent repo? Will the many eyeballs even see those errors when they’re intermingled with code implementing some compelling new feature? ## <a name="timestamps"></a>4.0 Rebase causes timestamp confusion Consider the earlier example of rebasing a feature branch: |
︙ |