pub struct Client { /* private fields */ }Expand description
HTTP client for the git-lfs API endpoints.
One instance per LFS endpoint URL. Client is cheap to clone and shares
an underlying connection pool — clone freely.
§Authentication
Two complementary mechanisms:
Authpassed at construction is the initial auth — applied to every request, no retries on 401.- A credential helper attached via
Self::with_credential_helperis queried on a 401 response: the request is retried once with the filled-in credentials, and the helper is toldapprove/rejectbased on the second attempt’s outcome. Once a fill succeeds, the client remembers the credentials and uses them for subsequent requests, so the 401 dance only happens at most once per process.
Implementations§
Source§impl Client
impl Client
Sourcepub async fn batch(&self, req: &BatchRequest) -> Result<BatchResponse, ApiError>
pub async fn batch(&self, req: &BatchRequest) -> Result<BatchResponse, ApiError>
POST /objects/batch to negotiate transfer URLs.
Source§impl Client
impl Client
Sourcepub fn new(endpoint: Url, auth: Auth) -> Self
pub fn new(endpoint: Url, auth: Auth) -> Self
Build a client rooted at the given LFS endpoint.
endpoint is the LFS server URL (e.g.
https://git-server.com/foo/bar.git/info/lfs). Subpaths
(/objects/batch, /locks, …) are joined onto it per request.
Sourcepub fn with_http_client(endpoint: Url, auth: Auth, http: Client) -> Self
pub fn with_http_client(endpoint: Url, auth: Auth, http: Client) -> Self
Like new but reuses a caller-supplied reqwest::Client.
Useful for sharing a connection pool, custom timeouts, proxies, etc.
Sourcepub fn with_credential_helper(self, helper: Arc<dyn Helper>) -> Self
pub fn with_credential_helper(self, helper: Arc<dyn Helper>) -> Self
Attach a credential helper. On 401, the client will call
helper.fill, retry once with the result, then approve/reject
based on the outcome.
Source§impl Client
impl Client
Sourcepub async fn create_lock(
&self,
req: &CreateLockRequest,
) -> Result<Lock, CreateLockError>
pub async fn create_lock( &self, req: &CreateLockRequest, ) -> Result<Lock, CreateLockError>
POST /locks to create a new lock.
Body decoding is flexible to accommodate both spec’d 409 → existing
lock responses and the reference test server’s “200 with message
but no lock” in-band-conflict pattern.
Sourcepub async fn list_locks(
&self,
filter: &ListLocksFilter,
) -> Result<LockList, ApiError>
pub async fn list_locks( &self, filter: &ListLocksFilter, ) -> Result<LockList, ApiError>
GET /locks with optional filters.
Sourcepub async fn verify_locks(
&self,
req: &VerifyLocksRequest,
) -> Result<VerifyLocksResponse, ApiError>
pub async fn verify_locks( &self, req: &VerifyLocksRequest, ) -> Result<VerifyLocksResponse, ApiError>
POST /locks/verify to list locks partitioned into ours/theirs.
Per the spec, servers that don’t implement locking can return 404
here; that surfaces as ApiError::Status { status: 404, .. }. The
caller (typically push) should treat that as “no locks to verify”
rather than a hard failure — see is_not_found().
Sourcepub async fn delete_lock(
&self,
id: &str,
req: &DeleteLockRequest,
) -> Result<Lock, ApiError>
pub async fn delete_lock( &self, id: &str, req: &DeleteLockRequest, ) -> Result<Lock, ApiError>
POST /locks/{id}/unlock to delete a lock.