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 checkout
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 wait until the filter is d
> 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 requests). During this process the Git checkout
>> o
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 also terminated with a flush p
Junio C Hamano writes:
+ filter->string = "";
+ continue;
+ }
+
+ /* In dco->paths we store a list of all delayed paths.
+ The filter just send us a list of availa
> 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" response. The list subtraction done by the calle
6 matches
Mail list logo