From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Jialong Wang <jerrywang183@yahoo.com>, git@vger.kernel.org
Subject: Re: [GSoC PATCH v2] object-name: turn INTERPRET_BRANCH_* constants into enum values
Date: Fri, 20 Mar 2026 13:12:21 -0700 [thread overview]
Message-ID: <xmqqh5qadzve.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZTfL+1wqLYLNES-o1bCMJnms7rp1hG=DN+=YStgc38+vA@mail.gmail.com> (Karthik Nayak's message of "Fri, 20 Mar 2026 03:25:43 -0700")
Karthik Nayak <karthik.188@gmail.com> writes:
>> diff --git a/object-name.h b/object-name.h
>> index cda4934cd5..167a9154ea 100644
>> --- a/object-name.h
>> +++ b/object-name.h
>> @@ -101,9 +101,12 @@ int set_disambiguate_hint_config(const char *var, const char *value);
>> * If the input was ok but there are not N branch switches in the
>> * reflog, it returns 0.
>> */
>> -#define INTERPRET_BRANCH_LOCAL (1<<0)
>> -#define INTERPRET_BRANCH_REMOTE (1<<1)
>> -#define INTERPRET_BRANCH_HEAD (1<<2)
>> +enum interpret_branch_kind {
>> + INTERPRET_BRANCH_LOCAL = (1 << 0),
>> + INTERPRET_BRANCH_REMOTE = (1 << 1),
>> + INTERPRET_BRANCH_HEAD = (1 << 2),
>> +};
>
> Generally when we use preprocessor constants with bit setting like
> `1 << 0`, we want to use them as flags which aren't mutually exclusive,
> allowing us to do 'INTERPRET_BRANCH_LOCAL | INTERPRET_BRANCH_HEAD' and
> so on.
>
> Is this the case here? If not, maybe we want to mention that explicitly
> and simply use '1, 2....N'?
Taking a brief look at the way these constants are used, e.g.,
static int branch_interpret_allowed(const char *refname, unsigned allowed)
{
if (!allowed)
return 1;
if ((allowed & INTERPRET_BRANCH_LOCAL) &&
starts_with(refname, "refs/heads/"))
return 1;
if ((allowed & INTERPRET_BRANCH_REMOTE) &&
starts_with(refname, "refs/remotes/"))
return 1;
return 0;
}
it should be obvious that these are not mutually exclusive choices,
rather they are independent flags that you can flip ON to express
dwimming a short name to what types of branches are allowed.
Besides, the original assignes one-bit-per-value to these constants;
it is not a place for this "CPP macro turned into enum to help those
who inspect a running program with gdb" patch to change assignments
of values. That would be a separate topic.
prev parent reply other threads:[~2026-03-20 20:12 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
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 [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=xmqqh5qadzve.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