{"thread":{"id":"63989","subject":"git: prepare to regularly change hashsums","startedAt":"2025-08-19T14:25:32Z","lastAt":"2025-08-21T08:28:52Z","messageCount":4,"participants":["Askar Safin","brian m. carlson","Simon Richter"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"524447","messageId":"198c2b87f70.ff0fbb4065293.4919681043907358329@zohomail.com","threadId":"63989","inReplyTo":null,"subject":"git: prepare to regularly change hashsums","fromName":"Askar Safin","fromEmail":"safinaskar@zohomail.com","sentAt":"2025-08-19T14:25:27Z","receivedAt":"2025-08-19T14:25:32Z","isPatch":false,"sender":{"key":"safinaskar@zohomail.com","avatar":null},"body":"Hi, git people. I just noticed that you plan to change default hashsum in git 3.0.\nCool!\n\nPlease, prepare for regular change of hashsum.\nNo hash is forever. Be prepared to change hashsum algorithm once in 10 years.\nSee here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html\n\n--\nAskar Safin\nhttps://types.pl/@safinaskar\n\n"},{"id":"524488","messageId":"aKTqHTnOMp1LFNLD@fruit.crustytoothpaste.net","threadId":"63989","inReplyTo":"198c2b87f70.ff0fbb4065293.4919681043907358329@zohomail.com","subject":"Re: git: prepare to regularly change hashsums","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-08-19T21:18:21Z","receivedAt":"2025-08-19T21:18:23Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-08-19 at 14:25:27, Askar Safin wrote:\n> Hi, git people. I just noticed that you plan to change default hashsum in git 3.0.\n> Cool!\n\nThanks, I'm glad you're excited about it.  I am, too.\n\n> Please, prepare for regular change of hashsum.\n> No hash is forever. Be prepared to change hashsum algorithm once in 10 years.\n> See here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html\n\nYes, this was a goal of the project when I did that work.\n\nThere are many fewer places where we have hard-coded hash values in the\ntests and a lot more places where we compute values (for instance, if\nwhat the test wants to know is that we're three commits before HEAD,\nthen we write `HEAD~3` instead of a specific object ID).  Instead of\nlots of hard-coded 20- and 40-based constants throughout the code, we\nhave a few #define constants and a hash algorithm abstraction.\n\nIf we need to change the hash algorithm again, it will require\nsubstantially less work, and we'll have only 40 test files to change\nthis time (which is a major improvement over last time).\n\nI hope people also feel that the refactoring we did has made our\ncodebase easier to understand and more maintainable.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"524507","messageId":"e069a7ca-fba4-432a-9a05-a68b2b6ddbc7@hogyros.de","threadId":"63989","inReplyTo":"aKTqHTnOMp1LFNLD@fruit.crustytoothpaste.net","subject":"Re: git: prepare to regularly change hashsums","fromName":"Simon Richter","fromEmail":"simon.richter@hogyros.de","sentAt":"2025-08-20T05:55:43Z","receivedAt":"2025-08-20T06:01:03Z","isPatch":false,"sender":{"key":"simon.richter@hogyros.de","avatar":"https://gravatar.com/avatar/1192aa9fa5dd19ce258b12b044cc27111dd7cdb58d920dc2123a02a24f55b5c5?d=mp&s=160"},"body":"Hi,\n\nOn 8/20/25 6:18 AM, brian m. carlson wrote:\n\n> There are many fewer places where we have hard-coded hash values in the\n> tests and a lot more places where we compute values (for instance, if\n> what the test wants to know is that we're three commits before HEAD,\n> then we write `HEAD~3` instead of a specific object ID).  Instead of\n> lots of hard-coded 20- and 40-based constants throughout the code, we\n> have a few #define constants and a hash algorithm abstraction.\n\nFor me it would be great to still be able to use commit IDs in this way \nin the future.\n\nMy use case is a script that is able to build old versions of a project, \nbasically it is a long list of commit IDs that require me to change the \nbuild instructions, and \"is-child-of\" tests.\n\nSo e.g. in a project we switch from cmake to meson, and the CI script \nchecks if the commit we are building is derived from the commit that \nswitches cmake to meson (which has a known ID), if so, it configures \nusing meson, if not, it checks more commit IDs to find out if it should \nuse cmake, or just plain make.\n\nSo if the hash algorithm changes I need to either still be able to make \nancestor tests using the old IDs, or a quick way to convert them.\n\n    Simon\n"},{"id":"524630","messageId":"aKbYvbWWL0FGXpG7@fruit.crustytoothpaste.net","threadId":"63989","inReplyTo":"e069a7ca-fba4-432a-9a05-a68b2b6ddbc7@hogyros.de","subject":"Re: git: prepare to regularly change hashsums","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-08-21T08:28:45Z","receivedAt":"2025-08-21T08:28:52Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-08-20 at 05:55:43, Simon Richter wrote:\n> On 8/20/25 6:18 AM, brian m. carlson wrote:\n> \n> > There are many fewer places where we have hard-coded hash values in the\n> > tests and a lot more places where we compute values (for instance, if\n> > what the test wants to know is that we're three commits before HEAD,\n> > then we write `HEAD~3` instead of a specific object ID).  Instead of\n> > lots of hard-coded 20- and 40-based constants throughout the code, we\n> > have a few #define constants and a hash algorithm abstraction.\n> \n> For me it would be great to still be able to use commit IDs in this way in\n> the future.\n\nYou can continue to do use object IDs for this purpose: we're not\nremoving them or deprecating them in any way.  It's merely that for our\ntestsuite we're relying less on object IDs to make it less brittle.\n\n> So if the hash algorithm changes I need to either still be able to make\n> ancestor tests using the old IDs, or a quick way to convert them.\n\nExisting repositories will continue to use SHA-1 unless you actively\nconvert them.  The change is simply that _new_ repositories will use\nSHA-256 by default (again, you can say that you want to use SHA-1 for a\nnew repository, just as you can say you want to use SHA-256 now).\n\nI am working on code for interoperability between the two algorithms\nwhich will allow you to convert a repository simply by cloning into a\nrepository using both hash algorithms.  That is, the remote might be\nSHA-1, but your repository will have SHA-256 with SHA-1 compatibility\nenabled, and then you'll have both algorithms.  You'll be able to look\nup SHA-1 object IDs in that repository very similarly to SHA-256 object\nIDs and convert the two.\n\nThat code already exists and works if your repositories are not using\nshallow clone, partial clone, or submodules.  It just has yet to be sent\nupstream.  I need to improve a few things in the current status quo\nbefore I can send out the series.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}