W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
> On 24/07/16 18:16, Lars Schneider wrote:
>> On 23 Jul 2016, at 01:19, Ramsay Jones <ram...@ramsayjones.plus.com> wrote:
>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
[...]
>>>> 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.
This should be, if we agree that detecting misconfigured filters is a good
thing, tested.
>>
>> (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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
