Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Added section "2.8 Test Before Commit" to the fossil-v-git doc. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
e5ba45788b9938487af172163908af04 |
User & Date: | wyoung 2019-09-13 10:46:12.632 |
Context
2019-09-13
| ||
11:12 | Added section "7.0 Collapsing check-ins throws away valuable information" to rebaseharm.md, linked to from the previous throwaway comment about squashing a whole branch down to a single commit during rebase. This section explains an entire class of harms that come from rebase which wasn't previously covered. ... (check-in: c71fe99f9b user: wyoung tags: trunk) | |
10:46 | Added section "2.8 Test Before Commit" to the fossil-v-git doc. ... (check-in: e5ba45788b user: wyoung tags: trunk) | |
09:25 | Added a few paras to section 3.0 in rebaseharm.md, giving consequences of siloed development in Socratic fashion. ... (check-in: 924bf44d39 user: wyoung tags: trunk) | |
Changes
Changes to www/fossil-v-git.wiki.
︙ | ︙ | |||
50 51 52 53 54 55 56 57 58 59 60 61 62 63 | <td>Select contributors</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> <tr><td>SHA-2</td> <td>SHA-3</td></tr> </table></blockquote> <h3 id="features">2.1 Featureful</h3> Git provides file versioning services only, whereas Fossil adds | > > | 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 | <td>Select contributors</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> <tr><td>Commit first</td> <td>Test first</td></tr> <tr><td>SHA-2</td> <td>SHA-3</td></tr> </table></blockquote> <h3 id="features">2.1 Featureful</h3> Git provides file versioning services only, whereas Fossil adds |
︙ | ︙ | |||
591 592 593 594 595 596 597 | One commentator characterized Git as recording history according to the victors, whereas Fossil records history as it actually happened. We go into more detail on this topic in a separate article, [./rebaseharm.md | Rebase Considered Harmful]. | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | | 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 | One commentator characterized Git as recording history according to the victors, whereas Fossil records history as it actually happened. We go into more detail on this topic in a separate article, [./rebaseharm.md | Rebase Considered Harmful]. <h3 id="testing">2.8 Test Before Commit</h3> One of the things that falls out of Git's default separation of commit from push is that there are several Git sub-commands that jump straight to the commit step before a change could possibly be tested. Fossil, by contrast, makes the equivalent change to the local working check-out only, requiring a separate check-in step to commit the change. This design difference falls naturally out of Fossil's default-enabled autosync feature. The prime example in Git is rebasing: the change happens to the local repository immediately if successful, even though you haven't tested the change yet. It's possible to argue for such a design in a tool like Git which doesn't automatically push the change up to its parent, because you can still test the change before pushing local changes to the parent repo, but in the meantime you've made a durable change to your local Git repository's blockchain. You must do something drastic like <tt>git reset --hard</tt> to revert that rebase if it causes a problem. If you push your rebased local repo up to the parent without testing first, you've now committed the error on a public branch, effectively a violation of [https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing | the golden rule of rebasing]. Lesser examples are the Git <tt>merge</tt>, <tt>cherry-pick</tt>, and <tt>revert</tt> commands, all of which apply work from one branch onto another, and all of which do their work immediately without giving you an opportunity to test the change first locally unless you give the <tt>--no-commit</tt> option. Fossil cannot sensibly work that way because of its default-enabled autosync feature. Instead of jumping straight to the commit step, Fossil applies the proposed merge to the local working directory only, requiring a separate check-in step before the change is committed to the repository blockchain. This gives you a chance to test the change, whether manually, or by running your software's automatic tests, or both. Another difference is that because Fossil requires an explicit commit for a merge, it makes you give an explicit commit <i>message</i> for each merge, whereas Git writes that commit message itself by default unless you give the optional <tt>--edit</tt> flag to override it. We don't look at this difference as a workaround in Fossil for autosync, but instead as a test-first philosophical difference. When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. We think this is an inherently good thing. Incidentally, this is a good example of Git's messy command design. These three commands: <pre> $ git merge HASH $ git cherry-pick HASH $ git revert HASH </pre> ...are all the same command in Fossil: <pre> $ fossil merge HASH $ fossil merge --cherrypick HASH $ fossil merge --backout HASH </pre> If you think about it, they're all the same function: apply work done on one branch to another. All that changes between these commands is how much work gets applied — just one check-in or a whole branch — and the merge direction. This is the sort of thing we mean when we point out that Fossil's command interface is simpler than Git's: there are fewer concepts to keep track of in your mental model of Fossil's internal operation. Fossil's implementation of the feature is also simpler to describe. The online help for <tt> [/help?cmd=merge | fossil merge]</tt> is currently 41 lines long, whereas the aggregate man page length for the above three Git commands is over 1000 lines, much of it mutually redundant. (e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get described three different times, each time differently.) <h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> Fossil started out using 160-bit SHA-1 hashes to identify check-ins, just as in Git. That changed in early 2017 when news of the [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1 collisions were now practical to create. Two weeks later, the creator of Fossil delivered a new release allowing a clean migration to [https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with |
︙ | ︙ |