# git: prepare to regularly change hashsums 4 messages from 2025-08-19 to 2025-08-21. Participants: Askar Safin, brian m. carlson, Simon Richter. Thread: https://gitlist.dev/t/63989 ## Askar Safin, 2025-08-19 14:25 Subject: git: prepare to regularly change hashsums Message-ID: <198c2b87f70.ff0fbb4065293.4919681043907358329@zohomail.com> URL: https://gitlist.dev/e/198c2b87f70.ff0fbb4065293.4919681043907358329%40zohomail.com ``` Hi, git people. I just noticed that you plan to change default hashsum in git 3.0. Cool! Please, prepare for regular change of hashsum. No hash is forever. Be prepared to change hashsum algorithm once in 10 years. See here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html -- Askar Safin https://types.pl/@safinaskar ``` ## brian m. carlson, 2025-08-19 21:18 Subject: Re: git: prepare to regularly change hashsums Message-ID: URL: https://gitlist.dev/e/aKTqHTnOMp1LFNLD%40fruit.crustytoothpaste.net In-Reply-To: <198c2b87f70.ff0fbb4065293.4919681043907358329@zohomail.com> ``` On 2025-08-19 at 14:25:27, Askar Safin wrote: > Hi, git people. I just noticed that you plan to change default hashsum in git 3.0. > Cool! Thanks, I'm glad you're excited about it. I am, too. > Please, prepare for regular change of hashsum. > No hash is forever. Be prepared to change hashsum algorithm once in 10 years. > See here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html Yes, this was a goal of the project when I did that work. There are many fewer places where we have hard-coded hash values in the tests and a lot more places where we compute values (for instance, if what the test wants to know is that we're three commits before HEAD, then we write `HEAD~3` instead of a specific object ID). Instead of lots of hard-coded 20- and 40-based constants throughout the code, we have a few #define constants and a hash algorithm abstraction. If we need to change the hash algorithm again, it will require substantially less work, and we'll have only 40 test files to change this time (which is a major improvement over last time). I hope people also feel that the refactoring we did has made our codebase easier to understand and more maintainable. -- brian m. carlson (they/them) Toronto, Ontario, CA ``` ## Simon Richter, 2025-08-20 05:55 Subject: Re: git: prepare to regularly change hashsums Message-ID: URL: https://gitlist.dev/e/e069a7ca-fba4-432a-9a05-a68b2b6ddbc7%40hogyros.de In-Reply-To: ``` Hi, On 8/20/25 6:18 AM, brian m. carlson wrote: > There are many fewer places where we have hard-coded hash values in the > tests and a lot more places where we compute values (for instance, if > what the test wants to know is that we're three commits before HEAD, > then we write `HEAD~3` instead of a specific object ID). Instead of > lots of hard-coded 20- and 40-based constants throughout the code, we > have a few #define constants and a hash algorithm abstraction. For me it would be great to still be able to use commit IDs in this way in the future. My use case is a script that is able to build old versions of a project, basically it is a long list of commit IDs that require me to change the build instructions, and "is-child-of" tests. So e.g. in a project we switch from cmake to meson, and the CI script checks if the commit we are building is derived from the commit that switches cmake to meson (which has a known ID), if so, it configures using meson, if not, it checks more commit IDs to find out if it should use cmake, or just plain make. So if the hash algorithm changes I need to either still be able to make ancestor tests using the old IDs, or a quick way to convert them. Simon ``` ## brian m. carlson, 2025-08-21 08:28 Subject: Re: git: prepare to regularly change hashsums Message-ID: URL: https://gitlist.dev/e/aKbYvbWWL0FGXpG7%40fruit.crustytoothpaste.net In-Reply-To: ``` On 2025-08-20 at 05:55:43, Simon Richter wrote: > On 8/20/25 6:18 AM, brian m. carlson wrote: > > > There are many fewer places where we have hard-coded hash values in the > > tests and a lot more places where we compute values (for instance, if > > what the test wants to know is that we're three commits before HEAD, > > then we write `HEAD~3` instead of a specific object ID). Instead of > > lots of hard-coded 20- and 40-based constants throughout the code, we > > have a few #define constants and a hash algorithm abstraction. > > For me it would be great to still be able to use commit IDs in this way in > the future. You can continue to do use object IDs for this purpose: we're not removing them or deprecating them in any way. It's merely that for our testsuite we're relying less on object IDs to make it less brittle. > So if the hash algorithm changes I need to either still be able to make > ancestor tests using the old IDs, or a quick way to convert them. Existing repositories will continue to use SHA-1 unless you actively convert them. The change is simply that _new_ repositories will use SHA-256 by default (again, you can say that you want to use SHA-1 for a new repository, just as you can say you want to use SHA-256 now). I am working on code for interoperability between the two algorithms which will allow you to convert a repository simply by cloning into a repository using both hash algorithms. That is, the remote might be SHA-1, but your repository will have SHA-256 with SHA-1 compatibility enabled, and then you'll have both algorithms. You'll be able to look up SHA-1 object IDs in that repository very similarly to SHA-256 object IDs and convert the two. That code already exists and works if your repositories are not using shallow clone, partial clone, or submodules. It just has yet to be sent upstream. I need to improve a few things in the current status quo before I can send out the series. -- brian m. carlson (they/them) Toronto, Ontario, CA ```