On 3/22/17, Scott Robison <sc...@casaderobison.com> wrote: > > Let's say for the sake of argument that you somehow wind up with two > modified files in the same commit that have the same hash but different > contents. Fossil will read back the data it just wrote to ensure what went > into the repo can be correctly retrieved. One of the two files will fail, > and fossil will refuse to commit the data will a message. At that point you > can change a file in some little way to get past the problem. > > In any case, fossil won't allow you to commit two files with the same hash > given its verification steps.
Scott is completely correct. I just want to emphasize his "for the sake of argument". Though it is possible *in theory* to generate a collision, that is impossible in practice now that Fossil has switched to using Hardened-SHA1 instead of SHA1, and is especially impossible when using SHA3-256. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
