Jeff Hostetler <[email protected]> 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 ;-).
