Jeff King <p...@peff.net> writes: > On Sat, May 12, 2018 at 10:00:22AM +0200, Nguyễn Thái Ngọc Duy wrote: > >> diff --git a/revision.h b/revision.h >> index b8c47b98e2..72404e2599 100644 >> --- a/revision.h >> +++ b/revision.h >> @@ -6,6 +6,7 @@ >> #include "notes.h" >> #include "pretty.h" >> #include "diff.h" >> +#include "commit-slab.h" >> >> /* Remember to update object flag allocation in object.h */ >> #define SEEN (1u<<0) >> @@ -29,6 +30,7 @@ struct rev_info; >> struct log_info; >> struct string_list; >> struct saved_parents; >> +define_commit_slab(source_slab, char *); > > Since this one is a global, can we give it a name that ties it to the > revision machinery? Like "revision_source_slab" or something?
Should this one be global in the first place? Can we tie it to say "struct rev_info" or something? I'd somehow anticipate a far future where object flag bits used for traversal book-keeping would be moved out of the objects themselves and multiple simultanous traversal becomes reality. Not limited to this particular one, but we'd need to think how the commit_slab mechanism should interact with the_repository idea Stefan has been having fun with. If the object pool is maintained per in-core repository object, presumably we'd have more than one in-core instances of the same commit object if we have more than one repository objects, and decorating one with a slab data may not want to decorate the other one at the same time.
