Feature Request: Check if commit is existent via http-protocol

Hi there,

for the development of a git client on a SAP System we need to make sure that a specific commit is existent in a specific branch. For that we have to ask the git server for the related information via the http protocol. There are two option from my point of view to achieve this:

1) You can request a specific list of commits of a branch by index (e.g. 
"1 to 30 <sha1 of branch>" would send the first 30 commits from the 
server to the client of the branch "master"
2) You send a request to the git server to verify that a specific commit 
is within a specific branch´and the response is something like "TRUE" or 
the sha1 of the branch the commit belongs to (branch of the time the 
commit was created).

Best regards,

Marius Raht

On 2019-11-13 at 13:14:00, Marius Raht wrote:

I think there may be a misunderstanding of the design of the Git HTTP protocol. It's essentially a stateless version of the regular Git protocol which provides data transport (and as a side effect, ref discovery). It isn't designed to be an API that can be queried remotely, and so it intentionally supports an extremely limited set of functionality.

Git supports a massive number of ways to query data, and there's just no way to efficiently and securely support all of those methods natively over an API. In fact, some operations Git can perform are potentially expensive, and exposing an API to perform those is a security problem (due to DoS attacks).

Some of that functionality is available in various Git hosting solutions through their own APIs, but as far as I'm aware, there aren't any which perform this operation (which is essentially "git merge-base --is-ancestor"). If you want this functionality in a particular platform, I'd encourage you to reach out to the provider of that platform to ask them if they'd implement it. However, I don't think we're likely to implement it in Git's HTTP protocol.

Other contributors are welcome to chime in if anything I said seems incorrect or off base.

On Thu, Nov 14, 2019 at 02:52:44AM +0000, brian m. carlson wrote:

I think that's all accurate.

There's nothing to say we _couldn't_ provide a richer set of commands via Git's protocol. There are already uncommon ones like upload-archive. And people have talked about being able to offload git-grep requests to a server.

But it really opens a can of worms in terms of which operations to support, how to handle load, etc. The strategy so far for Git itself has been to keep servers relatively dumb, and clients interested in doing queries should clone and then do what they want locally. That's not the most efficient thing for clients that want to do one-off queries, but it keeps the boundaries clean. Even if we did implement more server-side operations, they'd almost certainly be disabled by default.

-Peff

If your Git server supports it, a partial solution is to do a partial clone, e.g.:

  git clone --filter=tree:0 --bare \
    https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux

And you can add --depth=10 if you want the last 10 commits in that branch too:

  git clone --filter=tree:0 --bare --depth=10 \
    https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux

This creates a partial clone with no local trees or blobs. If you're just doing ancestry checks with "git merge-base", that should be sufficient. (If you're doing anything else, trees and blobs will be downloaded as Git needs them.)