[RFC PATCH] fetch-pack: lazy fetch using tree:0

[Jonathan Tan <jonathantanmy@google.com>]

Support for partial clones with filtered trees was added in bc5975d24f
("list-objects-filter: implement filter tree:0", 2018-10-07), but
whenever a lazy fetch of a tree is done, besides the tree itself, some
other objects that it references are also fetched.

The "blob:none" filter was added to lazy fetches in 4c7f9567ea
("fetch-pack: exclude blobs when lazy-fetching trees", 2018-10-04) to
restrict blobs from being fetched, but it didn't restrict trees.
("tree:0", which would restrict all trees as well, wasn't added then
because "tree:0" was itself new and may not have been supported by Git
servers, as you can see from the dates of the commits.)

Now that "tree:0" has been supported in Git for a while, teach lazy
fetches to use "tree:0" instead of "blob:none".

(An alternative to doing this is to teach Git a new filter that only
returns exactly the objects requested, no more - but "tree:0" already
does that for us for now, hence this patch. If we were to support
filtering of commits in partial clones later, I think that specifying a
depth will work to restrict the commits returned, so we won't need an
additional filter anyway.)
---
This looks like a good change to me - in particular, it makes Git align
with the (in my opinion, reasonable) mental model that when we lazily
fetch something, we only fetch that thing. Some issues that I can think
about:

 - Some hosts like GitHub support some partial clone filters, but not
   "tree:0".
 - I haven't figured out the performance implications yet. If we want a
   tree, I think that we typically will want some of its subtrees, but
   not all.

Any thoughts?
---
 fetch-pack.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index 1734a573b0..655ec5d4a3 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1747,14 +1747,14 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
 		/*
 		 * The protocol does not support requesting that only the
 		 * wanted objects be sent, so approximate this by setting a
-		 * "blob:none" filter if no filter is already set. This works
-		 * for all object types: note that wanted blobs will still be
+		 * "tree:0" filter if no filter is already set. This works
+		 * for all object types: note that wanted blobs and trees will still be
 		 * sent because they are directly specified as a "want".
 		 *
 		 * NEEDSWORK: Add an option in the protocol to request that
 		 * only the wanted objects be sent, and implement it.
 		 */
-		parse_list_objects_filter(&args->filter_options, "blob:none");
+		parse_list_objects_filter(&args->filter_options, "tree:0");
 	}
 
 	if (version != protocol_v2 && !ref) {
-- 
2.25.1.696.g5e7596f4ac-goog