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

Jonathan Tan [off-list ref] 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.