-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Git server-side capabilities. #8
Labels
Comments
redrabbit
changed the title
Add support for Git protocol capabilities for receive and upload pack commands.
Add support for Git protocol capabilities for server-side commands.
Dec 1, 2017
2 tasks
redrabbit
changed the title
Add support for Git protocol capabilities for server-side commands.
Add support for Git server-side capabilities.
Oct 9, 2018
Commit 0e767f6 has been reverted. We do not actually support Currently libgit2 does not support generating thin packs. See libgit2/libgit2#5367. In order to support this capability, we would require writing the implementation ourselves. |
redrabbit
added a commit
that referenced
this issue
Aug 26, 2021
GitRekt.WireProtocol.reference_discovery/3 takes a third parameter representing extra server capabilities to be announced. Note that %UploadPack{} and %ReceivePack{} both allow passing extra capabilities on their own. This allow us to set capabilities based on the Git transport protocol. For example GitGud.SmartHTTPBackend announces "no-done" capability when running git-upload-pack. Note that capabilities passed with GitRekt.WireProtocol.new/3 are only available during the discovery state. See #8 for more details.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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=X
to 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_ref
in 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.WireProtocol
does 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
.The text was updated successfully, but these errors were encountered: