From: Junio C Hamano <gitster@pobox.com>
To: Jialong Wang <jerrywang183@yahoo.com>
Cc: git@vger.kernel.org, karthik.188@gmail.com
Subject: Re: [GSoC PATCH] object-name: turn INTERPRET_BRANCH_* constants into enum values
Date: Wed, 18 Mar 2026 09:27:09 -0700 [thread overview]
Message-ID: <xmqqjyv9gl2a.fsf@gitster.g> (raw)
In-Reply-To: <20260318003917.84792-1-jerrywang183@yahoo.com> (Jialong Wang's message of "Tue, 17 Mar 2026 20:39:17 -0400")
Jialong Wang <jerrywang183@yahoo.com> writes:
> Replace the INTERPRET_BRANCH_* preprocessor constants with enum values and use the enum type where these flags are stored or passed around.
>
> This keeps the existing bitmask semantics, but gives the branch-name interpretation flags a dedicated type instead of plain unsigned values.
> ---
Overlong lines without sign-off.
> @@ -1660,7 +1660,8 @@ static int interpret_empty_at(const char *name, int namelen, int len, struct str
>
> static int reinterpret(struct repository *r,
> const char *name, int namelen, int len,
> - struct strbuf *buf, unsigned allowed)
> + struct strbuf *buf,
> + enum interpret_branch_name_allowed allowed)
> {
> /* we have extra data, which might need further processing */
> struct strbuf tmp = STRBUF_INIT;
> @@ -1692,7 +1693,9 @@ static void set_shortened_ref(struct repository *r, struct strbuf *buf, const ch
> free(s);
> }
>
> -static int branch_interpret_allowed(const char *refname, unsigned allowed)
> +static int branch_interpret_allowed(
> + const char *refname,
> + enum interpret_branch_name_allowed allowed)
A funny way to wrap lines. Use what you have in the previous hunk
as a template, perhaps?
> +enum interpret_branch_name_allowed {
> + INTERPRET_BRANCH_LOCAL = (1 << 0),
> + INTERPRET_BRANCH_REMOTE = (1 << 1),
> + INTERPRET_BRANCH_HEAD = (1 << 2),
> +};
I do not think "allowed" matches what this set represents.
The way "reinterpret" uses a parameter of this type (or the bitmask)
is to specify which _kind_ of branches are _allowed_ to be considered
for its output. The bitset is used to specify the KIND that are
ALLOWED. The type should identify itself as representing the kinds
of branches, while the parameter name should reflect what these
kinds are telling the function to do (i.e., allowed).
I'd name it "enum interpret_branch_kind" or somehing, if I were
doing this patch. If the type can stay private to a single C file,
we may want to even lose "interpret_" prefix, but I do not think
that is the case.
By the way, in the longer term, the set may even want to be possibly
unified with what "git branch --list [--remote | --all]" internally
uses. At that point it might even become shorter set that looks
like
enum branch_kind {
BRANCH_LOCAL, BRANCH_REMOTE, BRANCH_HEAD,
};
or "enum ref_kind" that also covers different ref hierarchies like
"tags" and "notes".
Needless to say, I do *NOT* want you to be doing this as part of
this patch; I do *NOT* want you to drop INTERPRET_ prefix from the
names of enum elements in this patch, either.
next prev parent reply other threads:[~2026-03-18 16:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260318003917.84792-1-jerrywang183.ref@yahoo.com>
2026-03-18 0:39 ` [GSoC PATCH] object-name: turn INTERPRET_BRANCH_* constants into enum values Jialong Wang
2026-03-18 16:27 ` Junio C Hamano [this message]
2026-03-18 19:09 ` [GSoC PATCH v2] " Jialong Wang
2026-03-20 10:25 ` Karthik Nayak
2026-03-20 20:12 ` Junio C Hamano
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=xmqqjyv9gl2a.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jerrywang183@yahoo.com \
--cc=karthik.188@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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