Skip to main content

Crate git_lfs_api

Crate git_lfs_api 

Source
Expand description

HTTP client for the Git LFS batch and locking APIs.

Git LFS speaks to a server over HTTPS using two endpoints. The batch endpoint (POST /objects/batch) takes a list of OIDs and sizes and returns one transfer URL per object (plus any auth headers and an expiry window); the locking endpoint suite (/locks, /locks/verify, /locks/{id}/unlock, …) lets clients claim files to coordinate edits across users. See the batch spec and locking spec for the wire-protocol contract.

Client is the entry point. Construct one per endpoint URL with an initial Auth (None, Basic, or Bearer), optionally attach a credential helper via Client::with_credential_helper and an SshResolver via Client::with_ssh_resolver, then invoke the per-operation methods. Client is cheap to clone and shares an underlying connection pool.

Request and response types are split by operation. Batch uses BatchRequest and BatchResponse, with ObjectResult carrying either Actions or an ObjectError per object. Lock operations use CreateLockRequest, ListLocksFilter, VerifyLocksRequest, and DeleteLockRequest, with Lock, Owner, and Ref as the shared model types.

On a 401 the client queries the attached credential helper, retries once, and reports approve or reject based on the outcome. Successful fills are cached for the lifetime of the Client. SSH-mediated endpoints (via SshResolver) can swap in a replacement HTTPS URL and auth headers per request.

Failures surface as ApiError, with predicates (is_unauthorized, is_retryable, …) for dispatch without matching on the variant. Server-supplied Retry-After (on 429 or 5xx responses) reaches callers via ApiError::retry_after; parse_retry_after is exported for reuse on other response paths.

Byte transfer against action URLs lives in git-lfs-transfer; credential resolution lives in git-lfs-creds; server URL discovery from a git remote lives in git-lfs-git.

Structs§

Action
One concrete HTTP request the transfer adapter should make.
Actions
The set of next-step actions the server returned for one object.
BatchRequest
A POST body for /objects/batch.
BatchResponse
Response body from /objects/batch.
Client
HTTP client for the git-lfs API endpoints.
CreateLockRequest
POST /locks body.
DeleteLockRequest
POST /locks/{id}/unlock body. Requests deletion of a single lock.
ListLocksFilter
Filter for GET /locks. All fields are optional; absent ones are not sent on the wire.
Lock
A lock record returned by the locking API.
LockList
Response body from GET /locks. A page of locks plus an optional continuation cursor.
ObjectError
Per-object error inside a batch response.
ObjectResult
Per-object result inside a batch response.
ObjectSpec
One object the client wants to transfer.
Owner
User identity attached to a lock by the server.
Ref
A server refspec, used by both batch and locking requests for auth schemes that take the ref into account (added in LFS v2.4).
ServerError
The standard error body returned by the LFS server for non-2xx responses.
SshAuth
Resolved auth from a git-lfs-authenticate call.
VerifyLocksRequest
POST /locks/verify body. Asks the server to partition known locks into ours and theirs.
VerifyLocksResponse
Response body from POST /locks/verify. Locks split by owner.

Enums§

ApiError
Errors returned by the API client.
Auth
Authentication to attach to API requests.
CreateLockError
Errors specific to Client::create_lock.
Operation
Operation requested from the batch endpoint.
SshOperation
git-lfs-authenticate <path> <op> operation argument. Wire form is lowercase upload or download.

Traits§

SshResolver
Hook called once per LFS API request to resolve SSH-mediated auth.

Functions§

parse_retry_after
Parse a Retry-After header value.

Type Aliases§

SharedSshResolver
Type alias for the boxed-resolver field on Client.