"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2023-09-08 at 23:05:52, Eric W. Biederman wrote: >> >> I would like to see the SHA256 transition happen so I started playing >> with the k2204-transition-interop branch of brian m. carlson's tree. >> >> Before I go farther I need to some other folks to look at this and see >> if this is a general direction that the git project can stand. > > I'm really excited to see this and I think it's a great way forward. > I've taken a brief look at each patch, and I don't see anything that > should be a dealbreaker. I left a few comments, although I think your > mailserver is blocking mine at the moment, so you may not have received > them (hopefully you can read them on the list in the interim). I can. I will see if I can figure out what is happening with direct reception tomorrow. > You may also feel free to simply adjust the commit message for the > patches of mine you've modified without needing to document that you've > changed them. I expect that you will have changed them when you submit > them, if only to resolve conflicts. After all, Junio does so all the > time. Thanks. I was doing my best at striking a balance between giving credit where is credit is due, and pointing out the bugs are probably mine. >> This patchset is not complete it does not implement converting a >> received pack of the compatibility hash into the hash function of the >> repository, nor have I written any automated tests. Both need to happen >> before this is finalized. > > Speaking of tests, one set of tests I had intended to write and think > should be written, but had not yet implemented, is tests for > round-tripping objects. That is, the SHA-1 value we get for a revision > in a pure SHA-1 repository should obviously be the same as the SHA-1 > value we get in a SHA-256 repository in interop mode, and we should be > able to use the `test_oid_cache` functionality to hard-code the desired > objects. I think it would be also helpful to do this for fixed objects > that are doubly-signed (with both algorithms) as well, since that's a > tricky edge case that we'll want to avoid breaking. Other edge cases > will include things like merge commits, including octopus merges. Yes. I think we can use cat-file to do that. Have two repositories one in each format. Verify that when cat-file prints out an object given the native oid cat-file prints out what was put in. Similarly verify that when cat-file prints out an object given the compatibility oid cat-file prints out the expected conversion. That logic performed in both repositories should work. > But overall, I think this is a great improvement, and I'm very excited > to see someone picking up some of this work and moving it forward. > Thanks for doing so. Thanks. Then next goal is to get enough merged that I can test the round-trip conversions. More than anything else we need to know the conversion functionality is solid. Plus I expect that while 32 patches were important to show the scope of the work, but a bit much to fully review and merge all at once. Eric
