git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RFC: Separate commit identification from Merkle hashing

From
Eric S. Raymond <esr@thyrsus.com>
Date
May 23, 2019, 20:53 UTC
Message-ID
<20190523205313.GB69096@thyrsus.com>
In-Reply-To
<20190523200929.GA70860@google.com>
Jonathan Nieder <jrnieder@gmail.com>:
Show 6 quoted lines
> In other words, usually the benefit of supporting multiple hash
> functions as a reader is that you want the strength of the strongest
> of those hash functions and you need a migration path to get there.
> If you don't have a way to eventually drop support for the weaker
> hashes, then what benefit do you get from supporting multiple hash
> functions?

Not losing the capability to verify old parts of histories up to the strength of the old hash algorithm. Not perfect, but better than nothing.

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Previous: Jonathan NiederNext: Eric S. Raymond
Message 8 of 13 in “RFC: Separate commit identification from Merkle hashing”
  1. Eric S. RaymondMay 21, 2019
  2. Jonathan NiederMay 21, 2019
  3. Eric S. RaymondMay 21, 2019
  4. Jonathan NiederMay 21, 2019
  5. Eric S. RaymondMay 21, 2019
  6. Jakub NarebskiMay 23, 2019
  7. Jonathan NiederMay 23, 2019
  8. Eric S. RaymondMay 23, 2019
  9. Eric S. RaymondMay 23, 2019
  10. Jonathan NiederMay 23, 2019
  11. Eric S. RaymondMay 23, 2019
  12. Randall S. BeckerMay 23, 2019
  13. Ævar Arnfjörð BjarmasonMay 23, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.