You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support 'ofs-delta' capability: Server can send delta referring to its base by position in pack rather than by an obj-id. That is, they can send/read OBJ_OFS_DELTA (aka type 6) in a packfile.
Support 'side-band-64k' capability: Server can send multiplexed progress reports and error info interleaved with the packfile itself.
Support 'agent' capability: The server may send a capability of the form agent=X to notify the client that the server is running version X.
git-upload-pack
Support 'multi_ack' and 'multi_ack_detailed' capabilities: The server can potentially head off the client from walking any further down that particular branch of the client’s repository history.
Support 'no-done' capability: Without this capability in the smart HTTP protocol, the server session would end and the client has to make another trip to send "done" before the server can send the pack.
Support 'thin-pack' capability: This can reduce the network traffic significantly, but it requires the receiving end to know how to "thicken" these packs by adding the missing bases to the pack.
git-receive-pack
Support 'atomic' capability: If the pushing client requests this capability, the server will update the refs in one atomic transaction. Either all refs are updated or none. See git_transaction_lock_ref in libgit2.
Support 'report-status' capability: After unpacking and updating references the server will respond with whether the packfile unpacked successfully and if each reference was updated successfully.
Support 'quiet' capability: This only matters once we support 'side-band-64k'. Currently, GitRekt.WireProtocol does not output any human-readable progress messages.
Support 'delete-refs' capability: Client can sent zero-id values to delete references. Relatively easy to implement, we will something like GitRekt.Git.reference_delete/4.
Checkout the Git protocol capabilities documentation.
both
Server can send delta referring to its base by position in pack rather than by an obj-id. That is, they can send/read
OBJ_OFS_DELTA(aka type 6) in a packfile.Server can send multiplexed progress reports and error info interleaved with the packfile itself.
The server may send a capability of the form
agent=Xto notify the client that the server is running versionX.git-upload-pack
The server can potentially head off the client from walking any further down that particular branch of the client’s repository history.
Without this capability in the smart HTTP protocol, the server session would end and the client has to make another trip to send "done" before the server can send the pack.
This can reduce the network traffic significantly, but it requires the receiving end to know how to "thicken" these packs by adding the missing bases to the pack.
git-receive-pack
If the pushing client requests this capability, the server will update the refs in one atomic transaction. Either all refs are updated or none. See
git_transaction_lock_refin libgit2.After unpacking and updating references the server will respond with whether the packfile unpacked successfully and if each reference was updated successfully.
This only matters once we support 'side-band-64k'. Currently,
GitRekt.WireProtocoldoes not output any human-readable progress messages.Client can sent zero-id values to delete references. Relatively easy to implement, we will something like
GitRekt.Git.reference_delete/4.