Re: [PATCH] checkout: send commit provenance during prefetch

[Junio C Hamano <gitster@pobox.com>]

Jonathan Tan <jonathantanmy@google.com> writes:

> Therefore, teach the partial clone fetching mechanism to support a
> "provenance" argument, and plumb the commit provenance from checkout to
> the partial clone fetching mechanism.
>
> In the future, other commands can be similarly upgraded. Other possible
> future improvements include better diagnostic messages when a prefetch
> fails.

I am not sure "provenance" is a good word to describe the concept,
but it feels a bit too limiting that you can give only a single
commit, especially when ...

>  builtin/checkout.c       |  4 ++++
>  builtin/index-pack.c     |  2 +-
>  builtin/pack-objects.c   |  2 +-
>  diff.c                   |  2 +-
>  diffcore-rename.c        |  2 +-
>  promisor-remote.c        | 12 +++++++++---
>  promisor-remote.h        |  3 ++-
>  sha1-file.c              |  2 +-
>  t/t5616-partial-clone.sh |  7 +++++--
>  unpack-trees.c           |  3 ++-
>  unpack-trees.h           |  7 +++++++
>  11 files changed, 34 insertions(+), 12 deletions(-)

... I see that "diff" already needs lazy blob fetching and we know
diff often is between two commits (think: "git log -p").

> This essentially splits reachability-of-blob, which almost certainly
> requires loading a bitmap, into 2 parts: reachability-of-commit (which,
> from my limited experience, can be more quickly done using a regular
> object walk) and reachability-of-blob-from-commit (which, at worst,
> requires fewer bitmaps to be loaded). I don't have timings for how it
> works in practice, though.

What does the bitmap you have on the serving side typically tell
you?  For some selected commits (not all commits) you'd have a
bitmap that says "from this commit, these objects can be reached",
or is it "from this commit, these commits can be reached"?

Thanks.