Interesting. I imagined having endpoints like /download, /upload, and /verify. Having one endpoint that can send the correct hypermedia relations is better 👍

/cc @ddanier @meltingice since you've both worked on Git LFS server implementations.

Any thoughts on always sending and returning objects? So instead of:

[
  { "oid": "abcdef" }, ...
]

Send a hash. It gives us a place to add extra meta data for the request. Maybe we want to tell the server what the local commit is that we're downloading the objects for?

{
  "commit": "sha1",
  "branch": "master",
  "objects": [
    { "oid": "abcdef" }, ...
  ]
}

I like that idea 👍

Cool, I like this idea. Should help to speed things up a lot.

Is this going to be a mandatory endpoint, or is there some way the client can discover whether or not the server offers batching? Perhaps try the batch endpoint first, and then fall back to non-batched endpoints if it 404's?

Is this going to be a mandatory endpoint, or is there some way the client can discover whether or not the server offers batching? Perhaps try the batch endpoint first, and then fall back to non-batched endpoints if it 404's?

I'd like to transition the code to using the batch endpoint as the single required endpoint for servers to implement for Git LFS v1.0.

1. First, ship experimental support. Enable some local lfs.batch config on a repository to use it.
2. Make the batch API default, and fallback to the original API if the server returns a 404 or lfs.batch is false.
3. Remove support for the old /objects API.

I think a batch job would be really nice.

However I don't like the idea of adding additional data to the requests (commit sha1, branch). The git-lfs server is currently pretty easy to implement as it's basically a simple key value store. This is - in my eyes - one of the key features that make it a feasible solution for many git providers (GitLab could for example add this without many problems, I did my own implementation in just under 10 hours). Now just adding more information might not complicate things, but allow us to do so. In the end this might make implementations much harder.

Another thing to keep in mind is that we are talking about big files. So the API request to check a files existance should have a pretty low impact on the overall performance, most of the time should be spended up/downloading the file itself. So although adding a batch job is a great thing from a technical perspective it might not necessarily be that much better from a usability perspective. My personal opinion is to just implement it anyways, as you cannot change this so easily when more servers exist.

However I don't like the idea of adding additional data to the requests (commit sha1, branch).

I want to add this meta data in a way that's not required for servers to process. It should be easy to just focus on the proposed "objects" key if that's all your implementation cares about. I'm hoping to keep the API simple for small servers, with optional features that bigger servers can choose to implement.

So the API request to check a files existance should have a pretty low impact on the overall performance, most of the time should be spended up/downloading the file itself.

I hope to ship support for both APIs in the client first, defaulting to the current key/value methods. If we can't prove that reducing the API overhead helps in a meaningful way, we can scrap it. I'm anxious to compare this to the work done in #258.

I should add that since github.com does not yet have a batch api, any testing will need to be done against the lfs test server. A matching PR containing a batch endpoint is here: git-lfs/lfs-test-server#27

Merging this, as it seems like a great improvement, and will serve as a base for future changes.

As per #341 I'd really appreciate it if this capability could be made available via the SSH API in addition to HTTP.