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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.