larsxschnei...@gmail.com writes:
> From: Lars Schneider <larsxschnei...@gmail.com>
>
> Some `clean` / `smudge` filters might require a significant amount of
> time to process a single blob. During this process the Git checkout
> operation is blocked and Git needs to wait until the filter is done to
> continue with the checkout.
>
> Teach the filter process protocol (introduced in edcc858) to accept the
> status "delayed" as response to a filter request. Upon this response Git
> continues with the checkout operation and asks the filter to process the
> blob again after all other blobs have been processed.
Hmm, I would have expected that the basic flow would become
for each paths to be processed:
convert-to-worktree to buf
if not delayed:
do the caller's thing to use buf
else:
remember path
for each delayed paths:
ensure filter process finished processing for path
fetch the thing to buf from the process
do the caller's thing to use buf
and that would make quite a lot of sense. However, what is actually
implemented is a bit disappointing from that point of view. While
its first part is the same as above, the latter part instead does:
for each delayed paths:
checkout the path
Presumably, checkout_entry() does the "ensure that the process is
done converting" (otherwise the result is simply buggy), but what
disappoints me is that this does not allow callers that call
"convert-to-working-tree", whose interface is obtain the bytestream
in-core in the working tree representation, given an object in the
object-db representation in an in-core buffer, to _use_ the result
of the conversion. The caller does not have a chance to even see
the result as it is written straight to the filesystem, once it
calls checkout_delayed_entries().
