Re: [PATCH v4 11/12] convert: add filter.<driver>.process option

From: Jeff King <peff@peff.net>
Date: Aug 8, 2016, 16:26 UTC
Message-ID: <20160808162642.x4k7yjb5fxs2jp25@sigill.intra.peff.net>
In-Reply-To: <6D2101A9-2D01-47E8-9DFF-6C85DED4269D@gmail.com>

On Mon, Aug 08, 2016 at 06:21:18PM +0200, Lars Schneider wrote:

Show 17 quoted lines

> >> Happy answer with no content:
> >> ------------------------
> >> packet:          git< status=success\n
> >> ------------------------
> > 
> > This can just be spelled:
> > 
> >  git< status=success
> >  git< 0000
> >  git< 0000   # empty content!
> >  git< 0000   # empty list!
> 
> Is the first flush packet one too many?
> If there is nothing then I think we shouldn't
> send any packets?!
> 
> I agree with the remaining two flush packets.

There isn't nothing, there is a "status" field (though I think that should probably be required, so I guess you could imagine it as a stand-alone pkt, separate from the list terminated by the flush). But regardless, you need the first flush to say "I am done telling you up-front keys, now I am starting the content".

Otherwise, what would:

  git< status=success
  git< foo=bar
  git< 0000

be parsed as? Is "foo=bar" the first line of content, or the rest of the pre-content header? (You could guess if you could see the total conversation, but you can't; you have to parse it as it comes).

Show 14 quoted lines

> There is one more thing: I introduced a return value "status=error-all".
> Using this the filter can signal Git that it does not want to process
> any other file using the particular command.
> 
> Jakub came up with this idea here:
> 
> "Another response, which I think should be standarized, or at
> least described in the documentation, is filter driver refusing
> to filter further (e.g. git-LFS and network is down), to be not
> restarted by Git."
> 
> http://public-inbox.org/git/607c07fe-5b6f-fd67-13e1-705020c267ee%40gmail.com/
> 
> I think it is a good idea. Do you see arguments against it?

No, that seems reasonable (I would have just implemented that by hanging up the connection, but explicitly communicating is more robust).

-Peff