Re: [PATCH v1 3/3] convert: add filter.<driver>.useProtocol option

On 25 Jul 2016, at 01:22, Jakub Narębski [off-list ref] wrote:

W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:

quoted

On 24/07/16 18:16, Lars Schneider wrote:

quoted

On 23 Jul 2016, at 01:19, Ramsay Jones [off-list ref] wrote:

quoted

On 22/07/16 16:49, larsxschneider@gmail.com wrote:

[...]

quoted

quoted

quoted

quoted

This patch adds the filter.<driver>.useProtocol option which, if enabled,
keeps the external filter process running and processes all blobs with
the following protocol over stdin/stdout.

1. Git starts the filter on first usage and expects a welcome message
with protocol version number:
	Git <-- Filter: "git-filter-protocol\n"
	Git <-- Filter: "version 1"

Hmm, I was a bit surprised to see a 'filter' talk first (but so long as the
interaction is fully defined, I guess it doesn't matter).

It was a conscious decision to have the `filter` talk first. My reasoning was:

(1) I want a reliable way to distinguish the existing filter protocol ("single-shot 
invocation") from the new one ("long running"). I don't think there would be a
situation where the existing protocol would talk first. Therefore the users would
not accidentally mix them with a possibly half working, undetermined, outcome.

If an 'single-shot' filter were incorrectly configured, instead of a new one, then
the interaction could last a little while - since it would result in deadlock! ;-)

[If Git talks first instead, configuring a 'single-shot' filter _may_ still result
in a deadlock - depending on pipe size, etc.]

Would it be possible to do an equivalent of sending empty file to the filter?
If it is misconfigured old-style script, it would exit after possibly empty
output; if not, we would start new-style interaction.

I think we would need to close the pipe to communicate "end" to the filter, no?
I would prefer to define the protocol explicitly as this is clearly easier.

This should be, if we agree that detecting misconfigured filters is a good
thing, tested.

quoted

quoted

(2) In the future we could extend the pipe protocol (see $gmane/297994, it's very
interesting). A filter could check Git's version and then pick the most appropriate
filter protocol on startup.

Thanks,
Lars