Fossil

Check-in [d887a6d7]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Updated the discussion of SHA-3 support in Fossil within the fossil-v-git.wiki doc now that Fossil 2.10 is out. Basically, it changes the tense on all SHA-1 text to past tense.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: d887a6d74d7958c069a2da22345e8bd4b0c33a4bbb6ff62b01e2882192ce9642
User & Date: wyoung 2019-10-21 02:40:54.054
Context
2019-10-21
03:05
Moved all of the "Features found in Fossil but not in Git" up from section 3.1 into section 2.1 Featureful of the fossil-v-git doc, where such differences are otherwise covered. Removed section 3.2, giving the opposite case, since all of the Git features not found in Fossil are already covered elsewhere in the doc, sometimes more than once, as with the rebase issue. ... (check-in: d357f81b user: wyoung tags: trunk)
02:40
Updated the discussion of SHA-3 support in Fossil within the fossil-v-git.wiki doc now that Fossil 2.10 is out. Basically, it changes the tense on all SHA-1 text to past tense. ... (check-in: d887a6d7 user: wyoung tags: trunk)
01:53
Replaced brief footnote in fossil-v-git doc explaining why we use JavaScript (sparingly) with a reference to the new javascript.md doc, which explains this much more fully. ... (check-in: 21c7f1f8 user: wyoung tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/fossil-v-git.wiki.
︙︙
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529


<h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.

For example, the default "sync" behavior in Git is to only sync
a single branch, whereas with Fossil the only sync option it to
sync the entire DAG.  Git commands,
GitHub, and GitLab tend to show only a single branch at
a time, whereas Fossil usually shows all parallel branches at
once.  Git has commands like "rebase" that help keep all relevant
changes on a single branch, whereas Fossil encourages a style of
many concurrent branches constantly springing into existence,
undergoing active development in parallel for a few days or weeks, then








|
|








514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529


<h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.

For example, the default behavior in Git is to only synchronize
a single branch, whereas with Fossil the only sync option is to
sync the entire DAG.  Git commands,
GitHub, and GitLab tend to show only a single branch at
a time, whereas Fossil usually shows all parallel branches at
once.  Git has commands like "rebase" that help keep all relevant
changes on a single branch, whereas Fossil encourages a style of
many concurrent branches constantly springing into existence,
undergoing active development in parallel for a few days or weeks, then
︙︙
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732



733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748

Fossil's implementation of the feature is also simpler to describe. The
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
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
[./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based
repositories.

Here in mid-2019, that feature is now in every OS and package repository
known to include Fossil so that the next release



(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
effectively upgrading them to require Fossil 2.1 or newer. This
not only solves the SHAttered problem, it should prevent a reoccurrence
for the foreseeable future. With the current release (Fossil 2.9) only
repositories created before the
transition to Fossil 2 are still using SHA-1, and then only if the
repository's maintainer chose not to switch them into SHA-3 mode some
time over the past 2 years.

Meanwhile, the Git community took until August 2018 to announce
[https://git-scm.com/docs/hash-function-transition/2.18.0|their plan]
for solving the same problem by moving to SHA-256 (a variant of the
[https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until
February 2019 to release a version containing the change. It's looking
like this will take years more to percolate through the community.








|















|
|
>
>
>
|
|
<
|
|
<
<
<
<








708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737

738
739




740
741
742
743
744
745
746

Fossil's implementation of the feature is also simpler to describe. The
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 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
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
[./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based
repositories.

By mid-2019, that feature arrived in every software package repository
shipping Fossil, the last mover being Debian's stable package repo,
which has a highly conservative policy on upgrading to new versions.
With that hurdle run, we were able to change the default hash mode in
Fossil 2.10 (released 2019-10-04) to require SHA-3 support both for new
repositories and to create SHA-3 hashes in existing repos, effectively
upgrading them if they were created with Fossil 1.<i>x</i>. This not

only solves the SHAttered problem, it should prevent a reoccurrence of
similar problems for the foreseeable future.





Meanwhile, the Git community took until August 2018 to announce
[https://git-scm.com/docs/hash-function-transition/2.18.0|their plan]
for solving the same problem by moving to SHA-256 (a variant of the
[https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until
February 2019 to release a version containing the change. It's looking
like this will take years more to percolate through the community.
︙︙