Jeff King <peff@xxxxxxxx> writes: > Yeah, we send a special capability line in that case. If you do: > > GIT_TRACE_PACKET=1 git clone a b > > you can see that upload-pack indicates that ls-refs understands the > "unborn" capability: > > packet: upload-pack> version 2 > packet: upload-pack> agent=git/2.40.0.824.g7b678b1f643 > packet: upload-pack> ls-refs=unborn > packet: upload-pack> fetch=shallow wait-for-done > packet: upload-pack> server-option > packet: upload-pack> object-format=sha256 > packet: upload-pack> object-info > packet: upload-pack> 0000 > > And then clone asks for it say "yes, I also understand unborn": > > packet: clone> command=ls-refs > packet: clone> agent=git/2.40.0.824.g7b678b1f643 > packet: clone> object-format=sha256 > packet: clone> 0001 > packet: clone> peel > packet: clone> symrefs > packet: clone> unborn > packet: clone> ref-prefix HEAD > packet: clone> ref-prefix refs/heads/ > packet: clone> ref-prefix refs/tags/ > packet: clone> 0000 > > And then upload-pack can send us the extra information: > > packet: upload-pack> unborn HEAD symref-target:refs/heads/maestro > packet: upload-pack> 0000 > > I think we'd need to do something similar here for object-format. I guess we only need to touch "git clone" then. Without being asked, it advertsizes object-format=sha256 already, and when the maestro repository is prepared without --object-format=sha256, upload-pack advertises object-format=sha1 instead. So it probably is just the matter of capturing it and using it to populate the extensions.objectformat with an appropriate value.
