Re: [PATCH v2 0/5] Git filter protocol

From: Jeff King <peff@peff.net>
Date: Jul 29, 2016, 15:57 UTC
Message-ID: <20160729155740.GB29773@sigill.intra.peff.net>
In-Reply-To: <31219A33-CA8A-44D1-9DE0-6448AA1A7571@gmail.com>

On Fri, Jul 29, 2016 at 10:14:17AM +0200, Lars Schneider wrote:

> My current implementation supports only two cases. Either the filter
> knows the size and sends it back. Or the filter doesn't know the size
> and Git reads until the flush packet (your "unknown" case). "Approx" is 
> probably hard to do and fail shouldn't be part of the size, no?

Ah, OK, I missed that you could handle both cases. I think that is a reasonable approach. It means the filter has to bother with pkt-lines, but beyond that, it can choose the simple or streaming approach as appropriate.

> That being said a "fail" response is a very good idea! This allows
> the filter to communicate to git that a non required filter process
> failed. I will add that to the protocol. Thanks :)

Maybe just send "ok <size>", "ok -1" (for streaming), or "fail <reason>" followed by the content? That is similar to other Git protocols, though I am not sure they are good models for sanity or extensibility. :)

I don't know if you would want to leave room for other "headers" in the response, but you could also do something more HTTP-like, with a status code, and arbitrary headers. And presumably git would just ignore headers it doesn't know about. I think that's what Jakub's example was leaning towards. I'm just not sure what other headers are really useful, but it does leave room for extensibility.

-Peff