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. |
||
---|---|---|
.. | ||
api | ||
howto | ||
man | ||
proposals | ||
custom-transfers.md | ||
extensions.md | ||
linux-build.md | ||
README.md | ||
spec.md |
Git LFS Documentation
Reference Manual
Each Git LFS subcommand is documented in the official man pages. Any of these can also be viewed from the command line:
$ git lfs help <command>
$ git lfs <command> -h
Videos
- How to Work with Big Files - Quick intro to Git LFS.
Developer Docs
Details of how the Git LFS client works are in the official specification.
Details of how the GIT LFS server works are in the API specification.