Her entire section 2 (starting at 6:12) is basically about why git does not and will never allow mixing of SHA1 and SHA256.

The interop discussed is using copybara as a copy tool to move data from SHA1 based repos to SHA256 based repos and vice versa.

▲

RJIb8RBYxzAMX9u 8 hours ago | parent [-]

Thanks. I went back and re-watched that part, and her point's that "[a] tree's cryptographic strength is equal to the weakest hash algorithm anywhere in the tree," and that's fair. I also understand why Git 3.0 may not want to give user the choice, though I would still rather it be given.

	▲	amluto 7 hours ago \| parent \| next [-]
		> "[a] tree's cryptographic strength is equal to the weakest hash algorithm anywhere in the tree" This is simply wrong IMO, for two reasons: 1. The attack on SHA-1 is a collision attack. Once you have frozen a hash, you cannot attack it with existing cryptanalysis. If there were a preimage attack it would be a different story. 2. Even if there were preimage attacks, one could freeze a mapping from SHA1 hash to SHA-256 hash. In fact, #2 seems like en excellent design. Objects could reference such a mapping, and a repo could disallow conflicting mappings (the mappings would only be accepted if the mapped objects are reachable from the mapping and the mapping is correct).
	▲	schacon 8 hours ago \| parent \| prev [-]
		They do give the user the choice, but the default is changing. My point is not necessarily to rip out the SHA-256 option, but simply to not make it the default. Because then people will create repos in that format that do not understand the ramifications, where the opposite should be true.