{"id":28044,"date":"2020-02-04T15:35:27","date_gmt":"2020-02-04T20:35:27","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28044"},"modified":"2020-02-04T15:35:47","modified_gmt":"2020-02-04T20:35:47","slug":"a-new-hash-algorithm-for-git","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/02\/04\/a-new-hash-algorithm-for-git\/","title":{"rendered":"A New Hash Algorithm for Git"},"content":{"rendered":"

Jonathan Corbet<\/a> (via Hacker News<\/a>):<\/p>\n

\n

\nWith the hash algorithm abstracted out of the core Git code, the transition\nis, on the surface, relatively easy. A new version of Git can be made with\na different hash algorithm, along with a tool that will convert a\nrepository from the old hash to the new. With a simple command like:\n<\/p>

git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \\\n   \t--liability-waiver=none --use-shovels --carbon-offsets<\/pre>\n
\na user can leave SHA‑1 behind (note that the specific command-line options\nmay differ).  There is only one problem with this plan,\nthough: most Git repositories do not operate in a vacuum.  This sort of\nflag-day conversion might work for a tiny project, but it’s not going to\nwork well for a project like the kernel.\nSo Git needs to be able to work with both SHA‑1 and SHA‑256 hashes for the\nforeseeable future.  There are a number of implications to this requirement\nthat make themselves felt throughout the system.\n<\/p>\n
One of the transition design goals is that SHA‑256 repositories should be able to interoperate with SHA‑1 repositories managed by older versions of Git. If kernel.org updates to the new format, developers running older versions should still be able to pull from (and push to) that site. That will only happen if Git continues to track the SHA‑1 hashes for each object indefinitely.<\/p>\n<\/blockquote>\n\n
Previously:<\/p>\n