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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux