3f5fca598f
While SHA-256 is presently considered strong, it might not always be, so we should consider supporting other hash algorithms. We anticipate that, much like Git, exactly one hash algorithm will be in use at a time per repository. To make it easier for the client and server to negotiate a suitable algorithm, let's add a field to designate the hash algorithm in batch requests. This allows the client to declare to the server the hash algorithm on first upload, and the server can respond with the hash algorithm in use (if it supports multiple) or a 409 response if it cannot handle that. We expect clients and servers to both gracefully handle the absence of this value and assume SHA-256 if not specified. |
||
---|---|---|
.. | ||
schemas | ||
authentication.md | ||
basic-transfers.md | ||
batch.md | ||
locking.md | ||
README.md | ||
server-discovery.md |
Git LFS API
The Git LFS client uses an HTTPS server to coordinate fetching and storing large binary objects separately from a Git server. The basic process the client goes through looks like this:
- Discover the LFS Server to use.
- Apply Authentication.
- Make the request. See the Batch and File Locking API sections.
Batch API
The Batch API is used to request the ability to transfer LFS objects with the LFS server.
API Specification:
Current transfer adapters include:
Experimental transfer adapters include:
- Tus.io (upload only)
- Custom
File Locking API
The File Locking API is used to create, list, and delete locks, as well as verify that locks are respected in Git pushes.
API Specification: