From: "Ghanshyam Thakkar" <shyamthakkar001@gmail•com>
To: "Junio C Hamano" <gitster@pobox•com>,
"Meet Soni" <meetsoni3017@gmail•com>
Cc: git@vger•kernel.org, "Jeff King" <peff@peff•net>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail•com>,
"Patrick Steinhardt" <ps@pks•im>,
"Calvin Wan" <calvinwan@google•com>,
"Elijah Newren" <newren@gmail•com>
Subject: Re: [GSoC][RFC PATCH] show-branch: use commit-slab for flag storage
Date: Sun, 02 Mar 2025 18:26:52 +0530 [thread overview]
Message-ID: <D85SPKTTT47S.32GQ2NBP9J6I0@gmail.com> (raw)
In-Reply-To: <xmqqseobksfe.fsf@gitster.g>
On Wed Feb 19, 2025 at 12:10 AM IST, Junio C Hamano wrote:
> 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.
Agreed. Looking at the code, there seems to be two prequisites for
removing MAX_REVS limitation:
- Removing dependency on MAX_REVS for allocating arrays (ref_names,
revs, etc.)
(can convert these to heap allocation)
- Removing dependency on MAX_REVS for storing flags (which can be
achieved by using the slab mechanism and using some kind of bitset
API or we can use 'bitmap' from ewok.h)
Thanks.
prev parent reply other threads:[~2025-03-02 12:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 5:50 [GSoC][RFC PATCH] show-branch: use commit-slab for flag storage Meet Soni
2025-02-18 18:40 ` Junio C Hamano
2025-02-21 6:32 ` Jeff King
2025-02-21 17:15 ` Junio C Hamano
2025-02-25 1:17 ` Jeff King
2025-03-02 12:56 ` Ghanshyam Thakkar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D85SPKTTT47S.32GQ2NBP9J6I0@gmail.com \
--to=shyamthakkar001@gmail$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=calvinwan@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=meetsoni3017@gmail$(echo .)com \
--cc=newren@gmail$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox