Re: [PATCH 2/2] doc/gitremote-helpers: match object-format option docs to code

["Eric W. Biederman" <ebiederm@gmail.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> 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