Jeff King <peff@xxxxxxxx> writes: > I think a simpler solution would be that upon clearing the slab, we > either "finish" each commit (filling in the maybe_tree field) or > "unparse" it (unsetting the parsed flag, and then doing a regular and/or > graph lookup if it is accessed again later). Wow, that's clever. > It should be easy-ish to iterate through the slab and look at the > commits that are mentioned in it. Though maybe not? Each commit knows > its slab-id, but I'm not sure if we have a master list of commits to go > the other way. We have table of all in-core objects, don't we? > + * This will throw away the parents list, which is potentially sketchy. > + * A better version of this would just unset commit->object.parsed > + * and then do a minimal version of parse_commit() that _just_ loads > + * the tree data (and/or graph position if available). Yeah, it is a concern that we may be working with an in-core commit object whose parent list has already been rewritten during revision traversal. Well thought out. > + * > + * Naturally we'd need to drop the "const" from our commit above, too. > + */ > + unparse_commit(r, &commit->object.oid); > + repo_parse_commit(r, commit); > + > return NULL; > } > > I dunno. I do feel like this is a lurking maintenance headache, and > might even be a triggerable bug. But without knowing of a way that it > happens in the current code base, it feels like it would be easy to make > things worse rather than better. Unfortunately I share the feeling X-<. Thanks.
