"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2024-03-12 at 07:45:13, Jeff King wrote: >> So I guess my question was more of: are we thinking this explicit >> algorithm thing is coming very soon? If so, it might be worth keeping it >> in the docs. But if not, and it's just a hypothetical future, it may be >> better to clean things up now. And I ask you as the person who mostly >> juggles possible future algorithm plans in his head. ;) Of course if the >> answer is some combination of "I don't really remember what the plan >> was" and "I don't have time to work on it anytime soon" that's OK, too. Given the rest of the conversation I thought something about the object-format option was going to depend upon work that I am doing. Reading up on object-format this seems to be something that should be sorted out now. Fundamentally the object-format code is about a client representing a SHA256 repository encountering a server representing a SHA1 repository and detecting and handling that case cleanly. Or the other way around. This is a current concern as SHA1 and SHA256 repositories are both currently supported. The only future concern is what happens when a client for a SHA256 repository encounters a server serving a SHA1 repository and wants to switch into a compatibility mode, before it starts sending something that will confuse the server. That said I think a lot of think we do a lot of that today in practice by simply detecting the length of the hash. In general the plan is that all of the multiple hash interop work happens on the client and the server worries about handling a single hash efficiently. That said I haven't worked with the git protocol so I don't know what is needed in detail for a client to figure out what the server is speaking and cleanly abort, or quickly switch to the servers language. Jeff do you have any insight into that? > The answer is that I'm not planning on doing the SHA-1/SHA-256 interop > work except as part of my employment, since I'm kinda out of energy in > that area and it's a lot of work, and I don't believe that my employer > is planning to have me do that anytime soon. Thus, if nobody else is > planning on doing it in short order, it probably won't be getting done. > > I know Eric was working on some of the interop work, so perhaps he can > speak to whether he's planning on working in this area soonish. Soon-ish. Getting the SHA1/SHA256 interop working is something that I feel pretty strongly about. So once I can set aside some time I am going to push forward with it. I have code doing with pretty much everything else working and tested except the actual interop working at this point. That is I have code for bi-hash repositories. Breaking everything into small enough chunks that people don't feel daunted looking at the code has been a bit of a challenge. My current plan is to write some ``unit tests'' (that is tests that test a single abstraction in the code at a time), so I can feel comfortable feeding things in much smaller pieces. Once the core infrastructure is merged for bi-hash repositories then I plan to work on the actual interop between the repositories. With the challenging technical problem I have been looking at is quickly and efficiently writing a pack in the repository hash, while retaining a translation to it's original hash. Once the translation is done the rest is fiddly bits that should come fairly quickly and should be comparatively easy to review. AKA things like the client detecting the other end is using a different hash algorithm and using that information to send heads in a format the server understands. That said I will be happy to help sort out object-format now. That is maintenance and it has no dependencies that I am aware of. ... That said. Sorting out object-format has no dependencies on anything else I have been doing. I will be happy to help sort that out right now. Eric
