Re: Determining whether you have a commit locally, in a partial clone?

[Jeff King <peff@peff.net>]

On Tue, Jun 20, 2023 at 09:12:24PM +0200, Tao Klerks wrote:

> I'm back to begging for any hints here: Any idea how I can determine
> whether a given commit object exists locally, *without causing it to
> be fetched by the act of checking for it?*

This is not very efficient, but:

  git cat-file --batch-check='%(objectname)' --batch-all-objects --unordered |
  grep $some_sha1

will tell you whether we have the object locally.

I don't work with partial clones often, but it feels like being able to
say:

  git --no-partial-fetch cat-file ...

would be a useful primitive to have. The implementation might start
something like this:

diff --git a/object-file.c b/object-file.c
index 7c1af5c8db..494cdd7706 100644
--- a/object-file.c
+++ b/object-file.c
@@ -1555,6 +1555,14 @@ void disable_obj_read_lock(void)
 
 int fetch_if_missing = 1;
 
+static int allow_lazy_fetch(void)
+{
+	static int ret = -1;
+	if (ret < 0)
+		ret = git_env_bool("GIT_PARTIAL_FETCH", 1);
+	return ret;
+}
+
 static int do_oid_object_info_extended(struct repository *r,
 				       const struct object_id *oid,
 				       struct object_info *oi, unsigned flags)
@@ -1622,6 +1630,7 @@ static int do_oid_object_info_extended(struct repository *r,
 
 		/* Check if it is a missing object */
 		if (fetch_if_missing && repo_has_promisor_remote(r) &&
+		    allow_lazy_fetch() &&
 		    !already_retried &&
 		    !(flags & OBJECT_INFO_SKIP_FETCH_OBJECT)) {
 			promisor_remote_get_direct(r, real, 1);

and then have git.c populate the environment variable, similar to how we
handle --literal-pathspecs, etc.

That fetch_if_missing kind of does the same thing, but it's mostly
controlled by programs themselves which try to handle missing remote
objects specially. It does seem like you might be able to bend it to
your will here, though. I think without any patches that:

  git rev-list --objects --exclude-promisor-objects $oid

will tell you whether we have the object or not (since it turns off
fetch_if_missing, and thus will either succeed, printing nothing, or
bail if the object can't be found). It feels like --missing=error should
function similarly, but it seems to still lazy-fetch (I guess since it's
the default, the point is to just find truly unavailable objects). Using
--missing=print disables the lazy-fetch, but it seems to bail
immediately if you ask it about a missing object (I didn't dig, but my
guess is that --missing is mostly about objects we traverse, not the
initial tips).

-Peff