Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

> On 27 Jun 2017, at 00:13, Junio C Hamano wrote: > > Lars Schneider writes: > >> ... > >>> I am wondering whose responsibility it will be to deal with a path >>> "list-available" reports that are *not* asked by Git or Git got no >>> "delayed"

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Junio C Hamano writes: + filter->string = ""; + continue; + } + + /* In dco->paths we store a list of all delayed paths. + The filter just send

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: > Maybe this? > [...] If Git sends this command, then the > filter is expected to return a list of pathnames representing blobs > that have been delayed earlier and are now available. [...] OK. >>> +by a "success" status that is

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

> On 26 Jun 2017, at 21:02, Junio C Hamano wrote: > > Lars Schneider writes: > >> Some `clean` / `smudge` filters might require a significant amount of >> time to process a single blob (e.g. the Git LFS smudge filter might >> perform network

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: > Some `clean` / `smudge` filters might require a significant amount of > time to process a single blob (e.g. the Git LFS smudge filter might > perform network requests). During this process the Git checkout > operation is blocked and Git needs to

[PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

Some `clean` / `smudge` filters might require a significant amount of time to process a single blob (e.g. the Git LFS smudge filter might perform network requests). During this process the Git checkout operation is blocked and Git needs to wait until the filter is done to continue with the