"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
"Omar Polo" <op@omarpolo.com>
Subject:
Re: gitproto: match on capabilities value as well
To:
Stefan Sperling <stsp@stsp.name>
Cc:
gameoftrees@openbsd.org
Date:
Fri, 06 Feb 2026 19:23:03 +0100

Download raw body.

Thread
Stefan Sperling <stsp@stsp.name> wrote:
> On Fri, Feb 06, 2026 at 04:10:38PM +0100, Omar Polo wrote:
> > Hello,
> > 
> > This is a required step in supporting sha256 in the networking protocol.
> > 
> > I'm extracting this out because it's a bit tricky.
> > 
> > I'll soon add the object-format=sha256 capability to fetch and send, but
> > the current matching logic only looks at the capability name and ignore
> > the value.  So, if the server advertises object-format=sha1 we would
> > match it, even if we really wanted to "just" match on object-format=sha256.
> > 
> > Hence, I think that we should also match on the capabilities value.  ok?
> 
> There are capabilities which do not use values that are known ahead of
> time, such as push-cert=<nonce> or session-id=<session-id>.
> match_capability() would no longer be able to match such capabilities.

haven't thought about those since we don't seem to implement them, but
good point.

> object-format seems like a special case. Could this be handled outside
> of match_capability()? Like we do for the "symref" capability, above the
> loop which calls match_capability()?
> This way we could keep match_capability() simple.

Yeah, I can special case.  and in fact, i have to, as I was doing that
in a follow-up diff.  I'm just going to drop this and merge into the got
fetch one.