From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for every
single blob that is affected by a filter. If Git filters a lot of blobs
then the startup time of the external filter processes can become a
significant part of the overall Git execution time.
In a prel
On Wed, Aug 10, 2016 at 6:04 AM, wrote:
> From: Lars Schneider
>
> Git's clean/smudge mechanism invokes an external filter process for every
> single blob that is affected by a filter. If Git filters a lot of blobs
> then the startup time of the external filter processes can become a
> significa
On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
> > If the result content is empty then the filter is expected to respond
> > with a success status and an empty list.
> >
> > packet: git< status=success\n
> > packet: git<
> > packet:
On Fri, Aug 12, 2016 at 9:38 AM, Jeff King wrote:
> On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
>
>> > If the result content is empty then the filter is expected to respond
>> > with a success status and an empty list.
>> >
>> > packet: git< sta
> On 12 Aug 2016, at 18:33, Stefan Beller wrote:
>
> On Wed, Aug 10, 2016 at 6:04 AM, wrote:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a filter. If Git filters a lot of blobs
>> then the startup
On Fri, Aug 12, 2016 at 9:59 AM, Lars Schneider
wrote:
>
> The welcome message is necessary to distinguish the long running
> filter protocol (v2) from the current one-shot filter protocol (v1).
> This is becomes important if a users tries to use a v1 clean/smudge
> filter with the v2 git config s
> On 12 Aug 2016, at 18:48, Stefan Beller wrote:
>
> On Fri, Aug 12, 2016 at 9:38 AM, Jeff King wrote:
>> On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
>>
If the result content is empty then the filter is expected to respond
with a success status and an empty list.
>
Lars Schneider writes:
>> If we do the success first and then error out halfway, we
>> still have to clean up, so I do not see how this impacts
>> implementation?
>
> That is true. The reasoning is that an error in between is somewhat
> less expected. Therefore additional work is OK.
>
> An error
> On 12 Aug 2016, at 19:07, Stefan Beller wrote:
>
> On Fri, Aug 12, 2016 at 9:59 AM, Lars Schneider
> wrote:
>>
>> The welcome message is necessary to distinguish the long running
>> filter protocol (v2) from the current one-shot filter protocol (v1).
>> This is becomes important if a users t
> On 12 Aug 2016, at 19:13, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> If we do the success first and then error out halfway, we
>>> still have to clean up, so I do not see how this impacts
>>> implementation?
>>
>> That is true. The reasoning is that an error in between is somewh
Lars Schneider writes:
>> Unless the reasoning is "an error in between is so rare that we are
>> OK if the protocol misbehaves and the receiving end omits error
>> handing", I am not so sure how "therefore additional work is OK" is
>> a reasonable conclusion.
>
> Maybe I need to reword. An error
11 matches
Mail list logo