On Mar 3, 2017, at 6:29 AM, Richard Hipp <d...@sqlite.org> wrote: > > (1) When creating a new check-in, use the hash algorithm (SHA1 or > SHA3) that is used by the primary parent check-in.
I’m not certain what “primary” means in this context. I assume that it’s a distinction for cases where two “parents” exist, but what is the rule that determines which one is primary? For instance, when you’re cherrypicking, I assume the primary is the branch the cherrypick is being applied to, rather than the branch the cherrypicked change came from. Is that correct? How about merges? Is the primary parent the branch being merged into, rather than the branch being merged *in*? If all of that is correct, then this behavior seems sensible: the ongoing branch in both cases keeps its hash default rather than being “tainted” by the donor branch. > (2) Exception to (1) above: Use SHA3 for new check-ins if the --sha3 > command-line option is used. I’m confident that the vast majority of Fossil users don’t watch the mailing list, so they’ll be somewhat ignorant of the issues. They may hear that Fossil now uses SHA3, and they’ll upgrade and assume they’re using stronger hashes now, without realizing that they need to make an affirmative step to switch to the new-style hashes. Then years down the line, they’ll learn that all their checkins in that time are still SHA-1, and that there’s no easy way to go back and “fix” them, on purpose. You can say that it’s fixed by documenting the change, but we all know how RTFM arguments play out. On the other hand, it does provide a “don’t touch my tree” option to those who believe themselves informed and who wish not to upgrade anyway. I can see both sides. It’s a tough choice. I suppose given the alternative — someone in the latter camp forking Fossil 1.x — this is a better choice. > (3) New repositories are initialized using SHA3 That’s good. It solves my “defaults matter” concern. Hopefully the vast majority of *future* Fossil users haven’t even started using it yet, so that over time, we’ll still end up with a majority of SHA3-based repos. Maybe there should be a “fossil init --sha1” option for the technologically conservative. > (4) When new content is added by means other than a check-in > (examples: cluster artifacts added by the server on a sync, Wiki > pages, ticket attachments, or unversioned content files) then use the > hash algorithm that was used by the most recent check-in. That’s kind of random. If my trunk is SHA3 because I’ve remembered to give --sha3 on a recent checkin and my old stable branches are still SHA1 because I update them less than once a month on average, my non-checkin artifacts are going to use both until I get around to modifying each stable branch at least once while also remembering to update the hash algorithm. I think it would be better to use the hash style of tip-of-trunk instead. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
