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-14 at 12:47:16, Eric W. Biederman wrote:
>> 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.
>
> That's only true for the dumb HTTP protocol.  Everything else should not
> do that and we specifically want to avoid doing that, since we may very
> well end up with SHA-3-256 or another 256-bit hash instead of SHA-256 if
> there are sufficient cryptographic advances.

My apologies.  I thought Jeff King was reporting that object-format
extension did not work, and that had been masked by a test.

I see you saying and a quick grep through the code supports that the
object-format extension is implemented, and that the primary problem
is that the Documentation varies slightly from what is implemented.


Looking at the code I am left with the question:
 Is the object-format extension properly implemented in all cases?


If the object-format extension is properly implemented such that a
client and server mismatch can be detected I am for just Documenting
what is currently implemented and calling it good.

The reason for that is
Documentation/technical/hash-function-transition.txt does not expect
servers to support more than hash function.  I don't have a perspective
that differs.  So detecting what the client and server support and
failing if they differ should be good enough.



I am concerned that the current code may not report it's hash function
in all of the cases it needs to, to be able to detect a mismatch.

I look at commit 8b85ee4f47aa ("transport-helper: implement
object-format extensions") and I don't see anything that generates
":object-format=" after it has been asked for except the code
in remote-curl.c added in commit 7f60501775b2 ("remote-curl: implement
object-format extensions").

Maybe I am mistaken but a name like remote-curl has me strongly
suspecting that it does not cover all of the cases that git supports
that implement protocol v2.

I think I see some omissions in updating the protocol v2 Documentation.


Can some folks who understand how git protocol v2 is implemented better
that I do, tell me if I am seeing things or if it indeed looks like
there are some omissions in the object-format implementation?

Eric