Re: [PATCH 1/3] list-objects: add filter_blob to traverse_commit_list

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 28, 2017, 17:54 UTC
Message-ID: <xmqqa84svvyy.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <e2216ab8-5af7-4edd-16aa-f84a45e0cbd7@jeffhostetler.com>

Jeff Hostetler <git@jeffhostetler.com> writes:

Show 18 quoted lines

> Yes, my logic was a little confusing there.  Jonathan Tan said
> something similar the other day.  I have a new version that I'm
> working on now that looks like this:
>
> 	list_objects_filter_result r = LOFR_MARK_SEEN | LOFR_SHOW;
> 	...
> 	if (filter)
> 		r = filter(obj, path->buf, ...
> 	if (r & LOFR_MARK_SEEN)
> 		obj->flags |= SEEN;
> 	if (r & LOFR_SHOW)
> 		show(obj, path->buf, cb_data);
>
> I'm generalizing it a little to let the filter return 2 flags:
> () SEEN to indicate that the filter doesn't want to see it again
> () SHOW to include the object in the result.
> These let filters do "hard" and "provisional" omits.  (This will
> make more sense later when I get my patch cleaned up.)

It is not immediately obvious to me, especially without seeing the actual patch, why MARK_SEEN is needed. Especially given that I think a call to show() must set obj->flags |= SEEN anyway to avoid duplicate output, with or without the objects-filter mechanism.

But that question can and should wait.

Show 7 quoted lines

> Yes, I'm including similar logic inside process_tree() to allow that
> and let the filter know about entering and leaving each tree.  So we
> only need one filter-proc to handle a particular strategy and it will
> handle both tree and blob objects.
>
> I want to be able to use this mechanism to do narrow clone/fetch
> using such a filter-proc and a sparse-checkout-like spec.

Good to know ;-).