> On 09 Jan 2017, at 21:44, Stefan Beller wrote:
>
> On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider
> wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amount of time.
>> This blocks the entire Git
On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider
wrote:
> Hi,
>
> Git always performs a clean/smudge filter on files in sequential order.
> Sometimes a filter operation can take a noticeable amount of time.
> This blocks the entire Git process.
>
> I would like to give a filter process the possibil
Lars Schneider writes:
> What way do you think is better from a maintenance point of view?
> I prefer option 2 but I fear that these "special" values could confuse
> future readers of the code.
I recall getting confused by the redefinition of the meaning of
return value from the grep_directory()
> On 15 Nov 2016, at 19:03, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> The filter itself would need to be aware of parallelism
>>> if it lives for multiple objects, right?
>>
>> Correct. This way Git doesn't need to deal with threading...
>
> I think you need to be careful about
> On 17 Nov 2016, at 00:46, Junio C Hamano wrote:
>
> Jakub Narębski writes:
>
>>> I intend to implement this feature only for the new long running filter
>>> process protocol. OK with you?
>>
>> If I remember and understand it correctly, current version of long
>> running process protocol pr
Jakub Narębski writes:
>> I intend to implement this feature only for the new long running filter
>> process protocol. OK with you?
>
> If I remember and understand it correctly, current version of long
> running process protocol processes files sequentially, one by one:
> git sends file to filte
W dniu 16.11.2016 o 10:53, Lars Schneider pisze:
> On 15 Nov 2016, at 19:03, Junio C Hamano wrote:
>> Lars Schneider writes:
>>
The filter itself would need to be aware of parallelism
if it lives for multiple objects, right?
>>>
>>> Correct. This way Git doesn't need to deal with thread
Lars Schneider writes:
>> On 16 Nov 2016, at 19:15, Junio C Hamano wrote:
>>
>> Lars Schneider writes:
>>
* You'd need to rein in the maximum parallelism somehow, as you do
not want to see hundreds of competing filter processes starting
only to tell the main loop over an inde
> On 16 Nov 2016, at 19:15, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> * You'd need to rein in the maximum parallelism somehow, as you do
>>> not want to see hundreds of competing filter processes starting
>>> only to tell the main loop over an index with hundreds of entries
>>>
Lars Schneider writes:
>> * You'd need to rein in the maximum parallelism somehow, as you do
>> not want to see hundreds of competing filter processes starting
>> only to tell the main loop over an index with hundreds of entries
>> that they are delayed checkouts.
>
> I intend to implement
On 15 Nov 2016, at 19:03, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> The filter itself would need to be aware of parallelism
>>> if it lives for multiple objects, right?
>>
>> Correct. This way Git doesn't need to deal with threading...
>
> I think you need to be careful about thre
Lars Schneider wrote:
> > On 15 Nov 2016, at 02:03, Eric Wong wrote:
>
> > Anyways, I'll plan on doing something similar (in Perl) with the
> > synchronous parts of public-inbox which relies on "cat-file --batch"
> > at some point... (my rotational disks are slw :<)
>
> That sounds inte
Lars Schneider writes:
>> The filter itself would need to be aware of parallelism
>> if it lives for multiple objects, right?
>
> Correct. This way Git doesn't need to deal with threading...
I think you need to be careful about three things (at least; there
may be more):
* Codepaths that check
> On 15 Nov 2016, at 02:03, Eric Wong wrote:
>
> Lars Schneider wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amount of time.
>> This blocks the entire Git process.
>
> I have the same problem
Lars Schneider wrote:
> Hi,
>
> Git always performs a clean/smudge filter on files in sequential order.
> Sometimes a filter operation can take a noticeable amount of time.
> This blocks the entire Git process.
I have the same problem in many places which aren't git :>
> I would like to give a
Hi,
Git always performs a clean/smudge filter on files in sequential order.
Sometimes a filter operation can take a noticeable amount of time.
This blocks the entire Git process.
I would like to give a filter process the possibility to answer Git with
"I got your request, I am processing it, ask
16 matches
Mail list logo
