668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
|
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
|
-
-
-
-
-
+
+
+
+
+
+
+
+
+
|
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.)
brief online help for <tt>[/help?cmd=merge | fossil merge]</tt> is
currently 41 lines long, to which you want to add the 600 lines of
[./branching.wiki | the branching document]. The equivalent
documentation in Git is the aggregation of the man pages for the above
three commands, which 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.) Fossil's
documentation is not only more concise, it gives a nice split of brief
online help and full online documentation.
<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
|