[PATCH RFC v2 0/4] ref-filter: start using oid_object_info

[PATCH RFC v2 0/4] ref-filter: start using oid_object_info

[Оля Тележная]

Hello,
Discussion starts here: [1], [2].

Updates:

I fixed memory leaks, now we use data from oid_object_info() OR from
grab_commom_values() - not both as it was before.

I added support for "%(objectsize:disk)" atom (with tests) and for
"%(deltabase)" atom (without tests yet).
I didn't support "%(*objectsize:disk)" and "%(*deltabase)" because I
can't see the possibility to fill these fields at the same time with
other processes.
I really want to discuss this moment with someone. The best idea that
I have is to fully change grab_common_values() function so that it
would collect and fill all info from oid_object_info_extended(), and
we will invoke it before we actually get and parse full object.

I am not sure with this proposed solution at all: we would still have
the scenario when we call both oid_object_info_extended() and
get_object(), it means the performance will be worse in some cases. I
don't know if it's crucial.

By the way, do we have an official way to measure performance?

I didn't add tests for %(deltabase) atom because I am not sure that it
has sense for for-each-ref at all: I have a guess that I added this
atom only for future using in cat-file command, and also for deref
option %(*deltabase).

I was also thinking about adding new parameter to atom, something like
enum "need oid_object_info", "need get_object" etc, so that we could
collect all needed data in a shortest way. The problem is that the
code will be even more complicated, and I am not sure our goal worth
it. And, anyway, there would be the scenario when we have to call both
oid_object_info_extended() and get_object(): for example, if we have
format="%(objectsize:disk) %(author)".

Thanks a lot,
Waiting for any ideas/comments!

[1] https://public-inbox.org/git/CAL21Bm=6Z54-zsUq0DJqmqhSciHCDLUNXR8inDMAd-b-=QJjcA@mail.gmail.com/
[2] https://public-inbox.org/git/xmqq8t8la81a.fsf@gitster-ct.c.googlers.com/