threads / rfc / 48485

RFC patchref-filter: start using oid_object_info

Subject: [PATCH RFC 0/1] ref-filter: start using oid_object_info

## tl;dr

One message between May 14, 2018 and May 14, 2018. Diffs are folded; open one to read it.

replies: 0people: 1as markdown or json

Оля Тележная· May 14, 2018, 10:00 UTC · lore

Hello everyone, Some context at first: I am trying to migrate cat-file formatting part (I mean batch option) from its own implementation to ref-filter one. That's why I want to use oid_object_info_extended() in ref-filter, it will simplify my further work. Additionally, it will give us 2 new options (objectsize:disk and deltabase), and hopefully some commands could work faster because we will not get and parse whole object if we don't need it (invocation of oid_object_info_extended() is cheaper).

I am not sure if I need to add same logic for refs (I mean when we need to deref the object) - please share your opinion.

I also see the problem with sorting - that's the part of logic that I am trying not to touch at all. Data (from oid_object_info_extended()) is initialized in format_ref_array_item(), and we use it later in populate value(). We have get_ref_atom_value(), it uses populate_value(). The problem is that get_ref_atom_value() is used not only by format_ref_array_item(), but also by cmp_ref_sorting(). So, it means that data could be uninitialized in populate_value(). Now I do nothing with it, and it works fine because cmp_ref_sorting() works only with refs, and my code do not change refs logic for now. But it's bad, and I know about it.

I see 2 ways of fixing that: I need to support refs somehow; or, I need to add additional checks whether the data is initialized before. I will be happy to hear your opinion.

If you see other issues/ideas - please share your opinion, I appreciate it so much.

Thanks a lot! Olga

← back to recent threads