On Wed, May 2, 2018 at 10:17 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Tue, May 1, 2018 at 11:33 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> /* >> - * Holds any information related to accessing the raw object content. >> + * Holds any information needed to retrieve the raw content >> + * of objects. The object_parser uses this to get object >> + * content which it then parses. >> */ >> struct raw_object_store *objects; >> >> + /* >> + * State for the object parser. This owns all parsed objects >> + * (struct object) so callers do not have to manage their >> + * lifetime. >> + */ >> + struct object_parser *parsed_objects; > > I like this name 'parsed_objects'. Should we rename the struct after > it (e.g. parsed_object_store as opposed to raw_object_store above)? I can rename it to parsed_object_store for consistency. > Another suggestion is object_pool, if we keep 'struct object' instead > of 'struct parsed_object' and also want to keep current allocation > behavior: no individual deallocation. If you free, you free the whole > pool (e.g. you could run rev-list --all --objects in a separate pool, > once you're done, you delete the whole pool). That is what the following patches will be about, you can only free the whole set of parsed objects. So if you want to do a separate rev walk, you may need to instantiate a new repository for it (ideally you'd only need a separate parsed object store). I'd want to have the ability to have separate pools for submodules, such that they can be free'd on a per-repo basis. > -- > Duy
