Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> 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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> 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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> 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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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.

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> 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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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.

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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...

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> 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

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

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

RFC: Enable delayed responses to Git clean/smudge filter requests

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,