Re: [GSoC][RFC PATCH] show-branch: use commit-slab for flag storage

> Meet Soni <meetsoni3017@gmail.com> writes:
>
> > Replace direct accesses to commit->object.flags with the commit-slab
> > mechanism. Introduce `get_commit_flags()` and `set_commit_flags()` to
> > retrieve and update flags, respectively, and include `revision.h` so that
> > the canonical UNINTERESTING definition is used.
> >
> > Signed-off-by: Meet Soni <meetsoni3017@gmail.com>
>
> Ohhhh.  I thought people somehow have "refactored" the commit
> traversal code here to share more with the machinery used by the
> "log" family of commands, but the change in this patch being
> contained within the single "show-branch" file indicates that it is
> not the case, which is good ;-)
>
> And the MAX_REVS limitation has been with us from the very beginning
> of the "show-branch" command.  Lifting it is very good ;-) ;-).
>
> > ---
> > I'm not entirely sure what the TODO comment meant by storing a pointer to
> > the "ref name" directly, so I've assumed that the intent was to store
> > flags (of type int) directly in the commit-slab instead of commit->object.
>
> It has been forever since I looked at the code around here the last
> time, but I suspect that it meant the final mapping the code makes
> at the output phase from the bit position in the flags bits to which
> reference the bit (i.e. "I am reachable from that ref") could be
> omitted if we make the slab entry a set of (interned) refnames.
>
> But I think using a slab whose element is still a bag of bits that
> is wider than object.flags word is is the most straight-forward way
> to lift MAX_REVS limitation.  If we can leave everything else
> unchanged, that would be great.