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

From: Jeff King <peff@peff.net>
Date: Nov 14, 2019, 06:41 UTC
Message-ID: <20191114064137.GF10643@sigill.intra.peff.net>
In-Reply-To: <20191114025244.GC9216@camp.crustytoothpaste.net>

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

Show 16 quoted lines

> 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.

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