4 ms·

Git could have been written with a pluggable hash system, but for something that needs to be changed let's say once every ten years, is the up front cost really

• adrianN 10y ago
  How hard is it to introduce a global constant for the number of bits in your hash instead of writing char hash[40] everywhere?
  • pilif 10y ago
    That's not good enough though if you need to work with repositories that were made with previous releases. Just converting them is one thing, but what if you need to stay compatible indefinitely. And what about old releases that encounter a new repo? And what about URLs and emails that reference commit hashes? Think archives of mailing lists that suddenly become useless unless there's a way to keep both hashes around. Yes. These are all solvable problems (maybe not the old-release needing to handle new-style repo gracefully), but the complexity is much higher than upgrading a global constant.
    • adrianN 10y ago
      I think you could solve most problems by just enabling a different hash function with no backwards compatibility. Repositories have a format-version somewhere, and migrating from git to git-with-new-hash should be a fairly simple operation. You can always edit commit messages to add "corresponds to commit <sha1> in <old repo>". This is of course not as nice as full backwards compatibility, but it gets rid of the security problem for relatively cheap.
  • emn13 10y ago
    The problem isn't the number of bits (yet). The problem is the choice of hash. A truncated sha2 would still be fine for years to come (barring a sha2 break, which doesn't look imminent). 160bits may not be a huge margin, but it's still enough.