Emily's talk does a pretty good job of summarizing the issues with intermixing the hashes: https://youtu.be/eJJp0RE7cd4

RJIb8RBYxzAMX9u 9 hours ago | parent [-]

I skimmed the video, and I didn't quite catch that. Near the end of the video, however, she did mention that interop is in the works[0].

In any case, even if Git 3.0 were completely incompatible, it would suck, but it's not the end of the world. You just treat it as if you were migrating from one SCM system to another. CVS -> SVN -> Perforce -> Git -> Git 3.0 -> [...] been-there-done-that. This is something that both open-source and commercial projects have had to deal with over the years.

Or maybe it would be a repeat of Python 2.x -> 3.x. ¯\_(ツ)_/¯ With AI assistance, hopefully porting the tooling over may go a lot quicker and smoother.

[0] https://www.youtube.com/watch?v=eJJp0RE7cd4&t=1134s

▲

ba1afd89f34cb23 9 hours ago | parent | next [-]

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.

▲

schacon 8 hours ago | parent | prev [-]

My point is not that it's the end of the world (or the end of Git), but that it will be painful and unclear and confusing to lots of people. That would be fine if it made a huge difference in trust or protection, but it's the wrong way to do that.