Thread (1 message) 1 message, 1 author, 2017-06-28

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

From: Junio C Hamano <hidden>
Date: 2017-06-28 17:55:06

Jeff Hostetler [off-list ref] writes:
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.
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 ;-).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help