Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> Use release_revisions() to various users of "struct rev_list" which
> need to have their "struct rev_info" zero-initialized before we can
> start using it.
>
> To do this add a stub "REV_INFO_INIT" macro, ideally macro would be
> able to fully initialize a "struct rev_info", but all it does is the
> equivalent of assigning "{ 0 }" to the struct, the API user will still
> need to use repo_init_revisions(). In some future follow-up work we'll
> hopefully make REV_INFO_INIT be a "stand-alone" init likke STRBUF_INIT
> and other similar macros.
I do not think we want to leave such a misleading paragraph to
future developers.
Yes, We may want to move some of what init_revisions() does to
REV_INFO_INIT(), and for that, it helps to start using greppable
string REV_INFO_INT early rather than { 0 } to ease such transition,
and that is what we should be stressing, instead of ranting "it does
not do anything, so why are we stupidly introducing a name, instead
of writing { 0 }, which is what amounts to it anyway?" without
explicitly saying so but hinting with words like "stub", "all it
does is", and "will still need to".
Is that some kind of passive-aggressive thing?
You cannot use get_revision() even after calling init_revisions(),
and still need to use setup_revisions() before hand, but that does
not mean init_revisions() is not doing its job. It may be
implemented as the zero-initialization right now, but it misses the
point to put a stress on the fact that it doesn't do much now.
